From guilhem.vellut at gmail.com Mon May 1 10:49:42 2006 From: guilhem.vellut at gmail.com (Guilhem Vellut) Date: Mon, 1 May 2006 19:49:42 +0500 Subject: [Georuby-devel] Georuby 0.0.1 + new version of Spatial Adapter Message-ID: <4456200f.3e75d187.4f30.4c3d@mx.gmail.com> Hello, This post is to announce the release of a new version of GeoRuby, as well as updates to the spatial adapter for Rails. Georuby 0.1.1: Here is the list of changes: - Addition of support for M and Z dimension in the data types, as well as in the EWKB and EWKT parsers. - When creating a geometry, the presence of a Z or M dimension must be indicated. By default, the geometry is created in 2D and with a SRID of -1. - Suppression of as_binary, as_hex_binary and as_text. They have been replaced with as_ewkb, as_wkb, as_hex_ewkb, as_hex_wkb, as_ewkt and as_wkt. - Suppression of the static creation methods from_raw_point_sequence (for some geometric types) and from_raw_point_sequences (for other), to build a geometry from a list of point coordinates. They have been replaced by a from_coordinates for all types. - The static geometry construction method from_hexewkb has been replaced with from_hex_ewkb. GeoRuby documentation is available online: http://thepochisuperstarmegashow.com/ProjectsDoc/georuby-doc/index.html Here is a list of possible improvements for the next version : - Rewriting of the WKT parser to make it clearer - Any feature you would like to see? Spatial Adapter 0.1.1: The adapter for Rails has also been updated. The previously separate plugins for MySql and PostGIS have been merged into one, called "Spatial Adapter". Here are the changes: - The PostGIS adapter and the MySql Spatial adapter have been merged into one plugin. The correct file to load is determined using the type of connection defined in the environment. - Geometric columns can now be dumped just like other base data types. This means you can use the ruby schema mode, even if you use the plugin. - Support of M dimensions in migrations. The :dimension key in the column definition has disappeared and has been replaced by :with_z and :with_m. - Addition of unit tests. At the plugin root, Run "rake test:mysql" to run the mysql tests and "rake test:postgis" for the postgis ones. You will need to configure your connection in "test/db/database_mysql.yml" and "test/db/database_postgis.yml". Documentation for the adapter is available online: http://thepochisuperstarmegashow.com/ProjectsDoc/spatialadapter-doc/index.ht ml Here is a list of possible improvements for the next version: - Automatic generation of spatial queries for the geometric columns (in the spirit of the Rails find_by_... methods) - Support of other geometric datatype libraries in addition to GeoRuby (like Ruby/GEOS) - Proposals? guilhem From Chris.Ingrassia at fortiusone.com Tue May 2 09:45:49 2006 From: Chris.Ingrassia at fortiusone.com (Chris Ingrassia) Date: Tue, 2 May 2006 09:45:49 -0400 Subject: [Georuby-devel] as_hex_wkb vs as_hex_binary Message-ID: Quick question to clear up some confusion on my end... just pulled in the latest GeoRuby gem update and latest rev from the mysql_spatial_adapter repo (which was probably my first mistake... it wasn't really broken, so I probably shouldn't have been fixing it :). My tests started failing raising an exception from line 77 of mysql_spatial_adapter.rb, which looks like: "GeomFromWKB(0x#{value.as_hex_binary(2,false)},#{value.srid})" Changing it to "value.as_hex_wkb" instead of "value.as_hex_binary (2,false)" cleared it right up, but which one is "correct"? Is as_hex_binary going/gone, or is that line still technically correct within the scope of the next version? From guilhem.vellut at gmail.com Thu May 4 10:06:09 2006 From: guilhem.vellut at gmail.com (Guilhem Vellut) Date: Thu, 4 May 2006 19:06:09 +0500 Subject: [Georuby-devel] as_hex_wkb vs as_hex_binary Message-ID: <445a0a62.35d3ea8f.4854.ffffb872@mx.gmail.com> Hello. I actually changed the names of the ewkb export methods and their behavior. Before, you had to explicitly tell the export method (called as_hex_binary then) the dimension you wanted to export and if you did not want the SRID. The default was 2D and with SRID. So if you were working with 3D geometries and no SRID (ie default -1 SRID), you always had to add the arguments. Now, in the same case, as_hex_ewkb will by default export the geometry by keeping in the export all the information intact (here the 3D) and leave out the information it does not have (here the SRID). In most cases, this is what you would like I think. In any case, you can restrict what information to export by passing arguments. Another binary export method is provided for convenience, as_hex_wkb, which always restricts the output to 2D and no SRID, no matter what information is contained in the geometry to export (like for example 3D and with SRID). Since as_hex_wkb and as_hex_ewkb are both binary export methods, I removed the as_hex_binary so that there would be no confusion. In your specific case, if you use 2D and no SRID (ie default -1 SRID) directly in the geometries, as_hex_ewkb will actually by default export a strict WKB string (2D and no SRID, since this is all the information contained in the geometry). You can make it clearer that you are exporting strict WKB by using as_hex_wkb. This is what is done in the mysql adapter. I thought that maybe I should leave the former methods in for compatiblity, but since GeoRuby is still a very young library, I changed all the way by suppressing as_hex_binary and as_binary, which are now incorrect to use with the last GeoRuby version. Sorry for not having it made clearer in the release notes. I hope this cleared all the confusion. guilhem >>>>>>>>>>>>>> Quick question to clear up some confusion on my end... just pulled in the latest GeoRuby gem update and latest rev from the mysql_spatial_adapter repo (which was probably my first mistake... it wasn't really broken, so I probably shouldn't have been fixing it :). My tests started failing raising an exception from line 77 of mysql_spatial_adapter.rb, which looks like: "GeomFromWKB(0x#{value.as_hex_binary(2,false)},#{value.srid})" Changing it to "value.as_hex_wkb" instead of "value.as_hex_binary (2,false)" cleared it right up, but which one is "correct"? Is as_hex_binary going/gone, or is that line still technically correct within the scope of the next version? From wayne at waynekao.com Thu May 11 04:14:50 2006 From: wayne at waynekao.com (Wayne Kao) Date: Thu, 11 May 2006 01:14:50 -0700 Subject: [Georuby-devel] MySQL Point in unit test Message-ID: <000301c674d2$fdb85cb0$0702a8c0@devastation> Is there a way to express a MySQL Point in Rails YML for a model unit test? I've been trying something like this but it doesn't work since it becomes quoted and turns into 'GeomFromText(\'POINT(0 0)\')' wayne_user_profile: id: 1 some_point: GeomFromText('POINT(0 0)') created_on: 2002-12-30 updated_on: 2002-12-30 I can't make it NULL either since MySQL enforces that geospatial columns be non-NULL. So unless someone has an idea, my only option would be to not have a unit test for this model, which would be devastating. Thanks, --Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060511/b345388f/attachment.htm From guilhem.vellut at gmail.com Thu May 11 06:14:03 2006 From: guilhem.vellut at gmail.com (Guilhem Vellut) Date: Thu, 11 May 2006 15:14:03 +0500 Subject: [Georuby-devel] MySQL Point in unit test In-Reply-To: <000301c674d2$fdb85cb0$0702a8c0@devastation> Message-ID: <44630e84.2e7c49e0.5b03.08b6@mx.gmail.com> This would indeed be devastating. You can try to use the MySQL canonical form for geometries. It works when you try to insert a string in this form in a geometric column. The canonical form is as follows: 4 characters of code 255 followed by the strict WKB form of the geometry. In the context of your test, you could do: Wayne_user_profile: Id: 1 Some_point: <%= (255.chr * 4) + Geometry.from_ewkt( "POINT(0 0)").as_wkb %> Note that I haven't tried myself yet. If it works, I will update the adapter tonight with a method which can do it for you. In the meantime, you will have to do it manually. guilhem _____ From: georuby-devel-bounces at rubyforge.org [mailto:georuby-devel-bounces at rubyforge.org] On Behalf Of Wayne Kao Sent: 11 May 2006 13:15 To: georuby-devel at rubyforge.org Subject: [Georuby-devel] MySQL Point in unit test Is there a way to express a MySQL Point in Rails YML for a model unit test? I've been trying something like this but it doesn't work since it becomes quoted and turns into 'GeomFromText(\'POINT(0 0)\')' wayne_user_profile: id: 1 some_point: GeomFromText('POINT(0 0)') created_on: 2002-12-30 updated_on: 2002-12-30 I can't make it NULL either since MySQL enforces that geospatial columns be non-NULL. So unless someone has an idea, my only option would be to not have a unit test for this model, which would be devastating. Thanks, --Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060511/ce4f365b/attachment-0001.htm From wayne at waynekao.com Thu May 11 11:10:35 2006 From: wayne at waynekao.com (Wayne Kao) Date: Thu, 11 May 2006 08:10:35 -0700 Subject: [Georuby-devel] MySQL Point in unit test In-Reply-To: <44630e84.2e7c49e0.5b03.08b6@mx.gmail.com> Message-ID: <000601c6750d$10164f40$0702a8c0@devastation> Thanks for the suggestion, but that didn?t work, unfortunately, since it prints out a bunch of non-visible characters (code 255 for instance) that MySQL doesn?t like. E.g. INSERT INTO blah (' ??', ?1?, '2002-12-30', '2002-12-30'); ActiveRecord::StatementInvalid: Mysql::Error: #22003Cannot get geometry object from data you send to the GEOMETRY field Is that what it?s supposed to look like? The GeomFromText method seems to be the only way I can reliably get data in, but YML?s quoting makes using that impossible. --Wayne _____ From: Guilhem Vellut [mailto:guilhem.vellut at gmail.com] Sent: Thursday, May 11, 2006 3:14 AM To: 'Wayne Kao'; georuby-devel at rubyforge.org Subject: RE: [Georuby-devel] MySQL Point in unit test This would indeed be devastating. You can try to use the MySQL canonical form for geometries. It works when you try to insert a string in this form in a geometric column. The canonical form is as follows: 4 characters of code 255 followed by the strict WKB form of the geometry. In the context of your test, you could do: Wayne_user_profile: Id: 1 Some_point: <%= (255.chr * 4) + Geometry.from_ewkt( ?POINT(0 0)?).as_wkb %> Note that I haven?t tried myself yet. If it works, I will update the adapter tonight with a method which can do it for you. In the meantime, you will have to do it manually. guilhem _____ From: georuby-devel-bounces at rubyforge.org [mailto:georuby-devel-bounces at rubyforge.org] On Behalf Of Wayne Kao Sent: 11 May 2006 13:15 To: georuby-devel at rubyforge.org Subject: [Georuby-devel] MySQL Point in unit test Is there a way to express a MySQL Point in Rails YML for a model unit test? I?ve been trying something like this but it doesn?t work since it becomes quoted and turns into 'GeomFromText(\'POINT(0 0)\')' wayne_user_profile: id: 1 some_point: GeomFromText('POINT(0 0)') created_on: 2002-12-30 updated_on: 2002-12-30 I can?t make it NULL either since MySQL enforces that geospatial columns be non-NULL. So unless someone has an idea, my only option would be to not have a unit test for this model, which would be devastating. Thanks, --Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060511/c855e415/attachment.htm From guilhem.vellut at gmail.com Thu May 11 12:25:56 2006 From: guilhem.vellut at gmail.com (Guilhem Vellut) Date: Thu, 11 May 2006 21:25:56 +0500 Subject: [Georuby-devel] MySQL Point in unit test In-Reply-To: <000601c6750d$10164f40$0702a8c0@devastation> Message-ID: <446365a3.07bd35ea.1230.3b10@mx.gmail.com> I have read part of the YAML documentation. There is a !binary instruction to input binary data (http://yaml.org/type/binary.html). It must be followed with the binary data encoded in base64. So here is what I did: geom: <%= "!binary #{ [ (255.chr * 4) + Point.from_x_y(123.123,2345.65).as_wkb].pack('m') }" %> The .pack(?m?) is to instruct to encode in base64. If you could confirm that it works for you too, I will add a method which directly outputs this in the mysql adapter. guilhem _____ From: Wayne Kao [mailto:wayne at waynekao.com] Sent: 11 May 2006 20:11 To: 'Guilhem Vellut'; georuby-devel at rubyforge.org Subject: RE: [Georuby-devel] MySQL Point in unit test Thanks for the suggestion, but that didn?t work, unfortunately, since it prints out a bunch of non-visible characters (code 255 for instance) that MySQL doesn?t like. E.g. INSERT INTO blah (' ??', ?1?, '2002-12-30', '2002-12-30'); ActiveRecord::StatementInvalid: Mysql::Error: #22003Cannot get geometry object from data you send to the GEOMETRY field Is that what it?s supposed to look like? The GeomFromText method seems to be the only way I can reliably get data in, but YML?s quoting makes using that impossible. --Wayne _____ From: Guilhem Vellut [mailto:guilhem.vellut at gmail.com] Sent: Thursday, May 11, 2006 3:14 AM To: 'Wayne Kao'; georuby-devel at rubyforge.org Subject: RE: [Georuby-devel] MySQL Point in unit test This would indeed be devastating. You can try to use the MySQL canonical form for geometries. It works when you try to insert a string in this form in a geometric column. The canonical form is as follows: 4 characters of code 255 followed by the strict WKB form of the geometry. In the context of your test, you could do: Wayne_user_profile: Id: 1 Some_point: <%= (255.chr * 4) + Geometry.from_ewkt( ?POINT(0 0)?).as_wkb %> Note that I haven?t tried myself yet. If it works, I will update the adapter tonight with a method which can do it for you. In the meantime, you will have to do it manually. guilhem _____ From: georuby-devel-bounces at rubyforge.org [mailto:georuby-devel-bounces at rubyforge.org] On Behalf Of Wayne Kao Sent: 11 May 2006 13:15 To: georuby-devel at rubyforge.org Subject: [Georuby-devel] MySQL Point in unit test Is there a way to express a MySQL Point in Rails YML for a model unit test? I?ve been trying something like this but it doesn?t work since it becomes quoted and turns into 'GeomFromText(\'POINT(0 0)\')' wayne_user_profile: id: 1 some_point: GeomFromText('POINT(0 0)') created_on: 2002-12-30 updated_on: 2002-12-30 I can?t make it NULL either since MySQL enforces that geospatial columns be non-NULL. So unless someone has an idea, my only option would be to not have a unit test for this model, which would be devastating. Thanks, --Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060511/e11eead9/attachment-0001.htm From wayne at waynekao.com Thu May 11 12:51:57 2006 From: wayne at waynekao.com (Wayne Kao) Date: Thu, 11 May 2006 09:51:57 -0700 Subject: [Georuby-devel] MySQL Point in unit test In-Reply-To: <446365a3.07bd35ea.1230.3b10@mx.gmail.com> Message-ID: <000d01c6751b$39402630$6e01010a@devastation> Works great! I haven?t checked whether the point in the DB is actually 123.123, 2345.65, but my unit test passes now. Thanks! --Wayne _____ From: Guilhem Vellut [mailto:guilhem.vellut at gmail.com] Sent: Thursday, May 11, 2006 9:26 AM To: 'Wayne Kao'; georuby-devel at rubyforge.org Subject: RE: [Georuby-devel] MySQL Point in unit test I have read part of the YAML documentation. There is a !binary instruction to input binary data (http://yaml.org/type/binary.html). It must be followed with the binary data encoded in base64. So here is what I did: geom: <%= "!binary #{ [ (255.chr * 4) + Point.from_x_y(123.123,2345.65).as_wkb].pack('m') }" %> The .pack(?m?) is to instruct to encode in base64. If you could confirm that it works for you too, I will add a method which directly outputs this in the mysql adapter. guilhem _____ From: Wayne Kao [mailto:wayne at waynekao.com] Sent: 11 May 2006 20:11 To: 'Guilhem Vellut'; georuby-devel at rubyforge.org Subject: RE: [Georuby-devel] MySQL Point in unit test Thanks for the suggestion, but that didn?t work, unfortunately, since it prints out a bunch of non-visible characters (code 255 for instance) that MySQL doesn?t like. E.g. INSERT INTO blah (' ??', ?1?, '2002-12-30', '2002-12-30'); ActiveRecord::StatementInvalid: Mysql::Error: #22003Cannot get geometry object from data you send to the GEOMETRY field Is that what it?s supposed to look like? The GeomFromText method seems to be the only way I can reliably get data in, but YML?s quoting makes using that impossible. --Wayne _____ From: Guilhem Vellut [mailto:guilhem.vellut at gmail.com] Sent: Thursday, May 11, 2006 3:14 AM To: 'Wayne Kao'; georuby-devel at rubyforge.org Subject: RE: [Georuby-devel] MySQL Point in unit test This would indeed be devastating. You can try to use the MySQL canonical form for geometries. It works when you try to insert a string in this form in a geometric column. The canonical form is as follows: 4 characters of code 255 followed by the strict WKB form of the geometry. In the context of your test, you could do: Wayne_user_profile: Id: 1 Some_point: <%= (255.chr * 4) + Geometry.from_ewkt( ?POINT(0 0)?).as_wkb %> Note that I haven?t tried myself yet. If it works, I will update the adapter tonight with a method which can do it for you. In the meantime, you will have to do it manually. guilhem _____ From: georuby-devel-bounces at rubyforge.org [mailto:georuby-devel-bounces at rubyforge.org] On Behalf Of Wayne Kao Sent: 11 May 2006 13:15 To: georuby-devel at rubyforge.org Subject: [Georuby-devel] MySQL Point in unit test Is there a way to express a MySQL Point in Rails YML for a model unit test? I?ve been trying something like this but it doesn?t work since it becomes quoted and turns into 'GeomFromText(\'POINT(0 0)\')' wayne_user_profile: id: 1 some_point: GeomFromText('POINT(0 0)') created_on: 2002-12-30 updated_on: 2002-12-30 I can?t make it NULL either since MySQL enforces that geospatial columns be non-NULL. So unless someone has an idea, my only option would be to not have a unit test for this model, which would be devastating. Thanks, --Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060511/460f00ee/attachment.htm From guilhem.vellut at gmail.com Thu May 11 15:17:15 2006 From: guilhem.vellut at gmail.com (Guilhem Vellut) Date: Fri, 12 May 2006 00:17:15 +0500 Subject: [Georuby-devel] [ANN] to_yaml + find_by Message-ID: <44638dc8.037f1053.2bd6.ffffaaba@mx.gmail.com> == to_yaml Following the discussion with Wayne, I have added a to_yaml method to the class GeoRuby::SimpleFeatures::Geometry (it is actually added inside the spatial adapter and the body of the method is different for each database). It is in the current trunk. It is useful if you use YAML fixtures for your unit tests, since, at some point, you will want to input a geometry. You could transform your geometries to a form suitable for YAML yourself every time but to_yaml does it for you. You would use it like this, if the geom column is a point: fixture: id: 1 data: HELLO geom: <%= Point.from_x_y(123.5,321.9).to_yaml %> == find_by Also, even though it is not related, a find_by method redefined for geometric columns has been added. Basically, instead of using the Rails default '=' operator, it uses a bounding box intersection: && in PostGIS and MBRIntersects in MySQL, which can both make use of a spatial index if one is present. You could use this query, for example, to grab only a "map frame" worth of data for display purpose. You have 2 ways to use the find_by_[geom_column]: Either by passing a geometric object directly, or passing an array with the 2 opposite corners of a bounding box (with 2 or 3 coordinates depending of the dimension of the data). Park.find_by_geom(LineString.from_coordinates([[1.4,5.6],[2.7,8.9],[1.6,5.6] ])) or Park.find_by_geom([[3,5.6],[19.98,5.9]]) In PostGIS, since you can only perform operations on geometries with the same SRID, you can add a third element representing the SRID of the bounding box to the array. It is by default set to -1: Park.find_by_geom([[3,5.6],[19.98,5.9],123]) guilhem From Chris.Ingrassia at fortiusone.com Thu May 18 11:00:57 2006 From: Chris.Ingrassia at fortiusone.com (Chris Ingrassia) Date: Thu, 18 May 2006 11:00:57 -0400 Subject: [Georuby-devel] Aggregate Envelopes in MySQL Message-ID: <35B5110E-450E-4754-A450-2B7618F81D55@fortiusone.com> I think I've mentioned this before, but I was looking for a way to get an aggregate Envelope for a collection of geometries from a MySQL table. I haven't really had any luck finding a built-in way to do that, but it was holding me up with something I needed to get done, so I came up with a way to hack it, although I think it's really ugly. Basically you have to extract the points from the exterior ring of the polygon envelope geometries returned from MySQL and do MIN([X|Y) (...)) on them. Here's a snippet from one of my models with an example ('geometry' is the name of the relevant geometry column): def minx calculate(:min, :all, :select => 'X(StartPoint(ExteriorRing (Envelope(geometry))))').to_f end def maxy calculate(:max, :all, :select => 'Y(PointN(ExteriorRing(Envelope (geometry)), 3))').to_f end I find that solution to be really, really ugly, but I don't think I'm going to do much better. I end up combining the min/max x and y values into a polygon later on. I was hoping that somebody out there might see that and might see something that I didn't and be able to point out a better way of doing this so I wouldn't be afraid to look at my code next week, but I'm not holding my breath :) Couple questions: 1. If anybody has a PostGIS database handy, can you confirm for me that it behaves differently, and that when you do something like: SELECT Extent(the_geom) from some_spatial_table; it returns a single row with the aggregate extent? 2. Would having an aggregate extent function built into the mysql part of spatial_adapter be useful? If so, I'll clean up my code and can probably get a patch out within the next day or two Thanks! -Chris From guilhem.vellut at gmail.com Thu May 18 12:40:19 2006 From: guilhem.vellut at gmail.com (Guilhem Vellut) Date: Thu, 18 May 2006 21:40:19 +0500 Subject: [Georuby-devel] Aggregate Envelopes in MySQL In-Reply-To: <35B5110E-450E-4754-A450-2B7618F81D55@fortiusone.com> Message-ID: <446ca386.7220c930.24fe.ffffccdd@mx.gmail.com> >1. If anybody has a PostGIS database handy, can you confirm for me >that it behaves differently, and that when you do something like: > >SELECT Extent(the_geom) from some_spatial_table; > >it returns a single row with the aggregate extent? That's right. Only one row is returned with the aggregate extent. >2. Would having an aggregate extent function built into the mysql >part of spatial_adapter be useful? If so, I'll clean up my code and >can probably get a patch out within the next day or two Sure. guilhem From Chris.Ingrassia at fortiusone.com Thu May 18 12:51:52 2006 From: Chris.Ingrassia at fortiusone.com (Chris Ingrassia) Date: Thu, 18 May 2006 12:51:52 -0400 Subject: [Georuby-devel] Aggregate Envelopes in MySQL In-Reply-To: <446ca386.7220c930.24fe.ffffccdd@mx.gmail.com> References: <446ca386.7220c930.24fe.ffffccdd@mx.gmail.com> Message-ID: <321E9376-40FC-4019-9824-49A5EF9C712E@fortiusone.com> Cool, thanks. I'll post a patch to the list in the near future. On May 18, 2006, at 12:40 PM, Guilhem Vellut wrote: >> 1. If anybody has a PostGIS database handy, can you confirm for me >> that it behaves differently, and that when you do something like: >> >> SELECT Extent(the_geom) from some_spatial_table; >> >> it returns a single row with the aggregate extent? > > That's right. Only one row is returned with the aggregate extent. > >> 2. Would having an aggregate extent function built into the mysql >> part of spatial_adapter be useful? If so, I'll clean up my code and >> can probably get a patch out within the next day or two > > Sure. > > guilhem > From dougcole at gmail.com Tue May 30 18:26:09 2006 From: dougcole at gmail.com (Doug Cole) Date: Tue, 30 May 2006 15:26:09 -0700 Subject: [Georuby-devel] post_gis_adapter's to_yaml function Message-ID: <7b8d80330605301526v17c58998k46cc10e27c366ed1@mail.gmail.com> Hello, I just tried to use the to_yaml function in the post_gis_adapter and ran across some problems: -first I got an error related to the number of arguments (1 for 0), looking through the yaml code it looks like there's an optional options hash so I simply redefined the function as "to_yaml( opts = {} )" -after fixing that I recieved the error "wrong argument type String (expected Data) (TypeError)" which I haven't tackled. anyone else run into these problems? I was trying to dump some point data from my postgres database to a fixture for testing. Simply removing the to_yaml definition fixed things, so that's how I've left it, but I thought I'd report the problem. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060530/81e442db/attachment.htm From guilhem.vellut at gmail.com Wed May 31 01:12:00 2006 From: guilhem.vellut at gmail.com (Guilhem Vellut) Date: Wed, 31 May 2006 10:12:00 +0500 Subject: [Georuby-devel] post_gis_adapter's to_yaml function In-Reply-To: <7b8d80330605301526v17c58998k46cc10e27c366ed1@mail.gmail.com> Message-ID: <447d25aa.04b3ad94.5749.ffffb94c@mx.gmail.com> Hello Doug, I don't have all the elements to solve your problem. When you write "looking through the yaml code it looks like there's an optional options hash", what yaml code are you referring to? And how are you trying to use the method? If you use it in fixtures, the to_yaml method for geometries is used the following way: first: id: 1 data: HELLO WORLD value: 3 geom: <%= Geometry.from_ewkt('POINT(1.4 5.67)').to_yaml %> And it outputs the canonical representation of the geometry for the target database (HexEWKB for PostGIS). guilhem _____ From: georuby-devel-bounces at rubyforge.org [mailto:georuby-devel-bounces at rubyforge.org] On Behalf Of Doug Cole Sent: 31 May 2006 03:26 To: georuby-devel at rubyforge.org Subject: [Georuby-devel] post_gis_adapter's to_yaml function Hello, I just tried to use the to_yaml function in the post_gis_adapter and ran across some problems: -first I got an error related to the number of arguments (1 for 0), looking through the yaml code it looks like there's an optional options hash so I simply redefined the function as "to_yaml( opts = {} )" -after fixing that I recieved the error "wrong argument type String (expected Data) (TypeError)" which I haven't tackled. anyone else run into these problems? I was trying to dump some point data from my postgres database to a fixture for testing. Simply removing the to_yaml definition fixed things, so that's how I've left it, but I thought I'd report the problem. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060531/8eb3e773/attachment.htm From dougcole at gmail.com Wed May 31 01:59:58 2006 From: dougcole at gmail.com (Doug Cole) Date: Tue, 30 May 2006 22:59:58 -0700 Subject: [Georuby-devel] post_gis_adapter's to_yaml function In-Reply-To: <447d25aa.04b3ad94.5749.ffffb94c@mx.gmail.com> References: <7b8d80330605301526v17c58998k46cc10e27c366ed1@mail.gmail.com> <447d25aa.04b3ad94.5749.ffffb94c@mx.gmail.com> Message-ID: <7b8d80330605302259x6dc96214gffa72e0182030f36@mail.gmail.com> Sorry, I should have been more specific. The code I was looking at that has reference to the optional hash array was the yaml code in the ruby standard library, where to_yaml is defined for the built in classes (yaml/rubytypes.rb) Here's a reference to the options hash: http://yaml4r.sourceforge.net/doc/page/the_options_hash.htm. I was trying to use the spatial adapter's to_yaml to dump part of my database to a yaml file, with the ar_fixtures plugin ( http://nubyonrails.com/articles/2005/12/27/dump-or-slurp-yaml-reference-data) basically the call boils down to converting an activeRecord's attributes to yaml (row.attributes.to_yaml). Like I said, simply removing the to_yaml function from the postgis_adapter fixed it for me, as yaml defaults to simply outputting all the instance variables, which works fine in my case. Doug -On a related note - I was reading the archives for this mailing list and saw that someone was trying to figure out how to get a Geometry column into their fixture. This is probably too late to help here, but Fixtures are run through the same interpreter as .rhtml files are so you can always do something along the lines of #{Point.from_x_y(x, y).to_yaml} if you're not sure...hope that helps. On 5/30/06, Guilhem Vellut wrote: > > Hello Doug, > > > > I don't have all the elements to solve your problem. When you write "looking > through the yaml code it looks like there's an optional options hash", what > yaml code are you referring to? And how are you trying to use the method? > > > > If you use it in fixtures, the to_yaml method for geometries is used the > following way: > > first: > > id: 1 > > data: HELLO WORLD > > value: 3 > > geom: <%= Geometry.from_ewkt('POINT(1.4 5.67)').to_yaml %> > > And it outputs the canonical representation of the geometry for the target > database (HexEWKB for PostGIS). > > > > guilhem > > > > > ------------------------------ > > *From:* georuby-devel-bounces at rubyforge.org [mailto: > georuby-devel-bounces at rubyforge.org] *On Behalf Of *Doug Cole > *Sent:* 31 May 2006 03:26 > *To:* georuby-devel at rubyforge.org > *Subject:* [Georuby-devel] post_gis_adapter's to_yaml function > > > > Hello, > I just tried to use the to_yaml function in the post_gis_adapter and ran > across some problems: > > -first I got an error related to the number of arguments (1 for 0), > looking through the yaml code it looks like there's an optional options hash > so I simply redefined the function as "to_yaml( opts = {} )" > > -after fixing that I recieved the error "wrong argument type String > (expected Data) (TypeError)" which I haven't tackled. > > anyone else run into these problems? I was trying to dump some point data > from my postgres database to a fixture for testing. Simply removing the > to_yaml definition fixed things, so that's how I've left it, but I thought > I'd report the problem. > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060530/2428f0b3/attachment.htm From guilhem.vellut at gmail.com Wed May 31 02:34:49 2006 From: guilhem.vellut at gmail.com (Guilhem Vellut) Date: Wed, 31 May 2006 11:34:49 +0500 Subject: [Georuby-devel] post_gis_adapter's to_yaml function In-Reply-To: <7b8d80330605302259x6dc96214gffa72e0182030f36@mail.gmail.com> Message-ID: <447d3913.2b5e1f73.3a61.ffffecea@mx.gmail.com> Ok thanks for the precision. It seems I needlessly added complexity. The to_yaml was added to the Geometry class to input geometries in fixtures. But as you have remarked, the general to_yaml seems to work just fine! (actually I was not aware it existed.) So I am going to remove the specific to_yaml right away. Thanks for your feedback. guilhem _____ From: Doug Cole [mailto:dougcole at gmail.com] Sent: 31 May 2006 11:00 To: georuby-devel at rubyforge.org Cc: Guilhem Vellut Subject: Re: [Georuby-devel] post_gis_adapter's to_yaml function Sorry, I should have been more specific. The code I was looking at that has reference to the optional hash array was the yaml code in the ruby standard library, where to_yaml is defined for the built in classes (yaml/rubytypes.rb) Here's a reference to the options hash: http://yaml4r.sourceforge.net/doc/page/the_options_hash.htm. I was trying to use the spatial adapter's to_yaml to dump part of my database to a yaml file, with the ar_fixtures plugin ( http://nubyonrails.com/articles/2005/12/27/dump-or-slurp-yaml-reference-data ) basically the call boils down to converting an activeRecord's attributes to yaml ( row.attributes.to_yaml). Like I said, simply removing the to_yaml function from the postgis_adapter fixed it for me, as yaml defaults to simply outputting all the instance variables, which works fine in my case. Doug -On a related note - I was reading the archives for this mailing list and saw that someone was trying to figure out how to get a Geometry column into their fixture. This is probably too late to help here, but Fixtures are run through the same interpreter as .rhtml files are so you can always do something along the lines of #{ Point.from_x_y(x, y).to_yaml} if you're not sure...hope that helps. On 5/30/06, Guilhem Vellut wrote: Hello Doug, I don't have all the elements to solve your problem. When you write "looking through the yaml code it looks like there's an optional options hash", what yaml code are you referring to? And how are you trying to use the method? If you use it in fixtures, the to_yaml method for geometries is used the following way: first: id: 1 data: HELLO WORLD value: 3 geom: <%= Geometry.from_ewkt('POINT(1.4 5.67)').to_yaml %> And it outputs the canonical representation of the geometry for the target database (HexEWKB for PostGIS). guilhem _____ From: georuby-devel-bounces at rubyforge.org [mailto: georuby-devel-bounces at rubyforge.org] On Behalf Of Doug Cole Sent: 31 May 2006 03:26 To: georuby-devel at rubyforge.org Subject: [Georuby-devel] post_gis_adapter's to_yaml function Hello, I just tried to use the to_yaml function in the post_gis_adapter and ran across some problems: -first I got an error related to the number of arguments (1 for 0), looking through the yaml code it looks like there's an optional options hash so I simply redefined the function as "to_yaml( opts = {} )" -after fixing that I recieved the error "wrong argument type String (expected Data) (TypeError)" which I haven't tackled. anyone else run into these problems? I was trying to dump some point data from my postgres database to a fixture for testing. Simply removing the to_yaml definition fixed things, so that's how I've left it, but I thought I'd report the problem. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060531/44832fb0/attachment-0001.htm From guilhem.vellut at gmail.com Wed May 31 03:55:38 2006 From: guilhem.vellut at gmail.com (Guilhem Vellut) Date: Wed, 31 May 2006 12:55:38 +0500 Subject: [Georuby-devel] post_gis_adapter's to_yaml function In-Reply-To: <7b8d80330605302259x6dc96214gffa72e0182030f36@mail.gmail.com> Message-ID: <447d4c05.2ed58dcc.0743.fffffe84@mx.gmail.com> Well actually, it does not work totally fine when trying to manually input a geometry in a fixture (with something like <%= Point.from_x_y(123.4,567.1).to_yaml %>), using the default "to_yaml" for objects of the YAML library. The problems are that the document separator ("---") is output and that the components of the Point are not indented, which makes the YAML parser crash when reading the fixture. Do you know of options to prevent that? Therefore for now I will keep the former to_yaml methods specific to geometries and rename them "to_fixture_format", so the dumping to YAML format can work, as well as the input of geometries in a fixture. guilhem _____ From: Doug Cole [mailto:dougcole at gmail.com] Sent: 31 May 2006 11:00 To: georuby-devel at rubyforge.org Cc: Guilhem Vellut Subject: Re: [Georuby-devel] post_gis_adapter's to_yaml function Sorry, I should have been more specific. The code I was looking at that has reference to the optional hash array was the yaml code in the ruby standard library, where to_yaml is defined for the built in classes (yaml/rubytypes.rb) Here's a reference to the options hash: http://yaml4r.sourceforge.net/doc/page/the_options_hash.htm. I was trying to use the spatial adapter's to_yaml to dump part of my database to a yaml file, with the ar_fixtures plugin ( http://nubyonrails.com/articles/2005/12/27/dump-or-slurp-yaml-reference-data ) basically the call boils down to converting an activeRecord's attributes to yaml ( row.attributes.to_yaml). Like I said, simply removing the to_yaml function from the postgis_adapter fixed it for me, as yaml defaults to simply outputting all the instance variables, which works fine in my case. Doug -On a related note - I was reading the archives for this mailing list and saw that someone was trying to figure out how to get a Geometry column into their fixture. This is probably too late to help here, but Fixtures are run through the same interpreter as .rhtml files are so you can always do something along the lines of #{ Point.from_x_y(x, y).to_yaml} if you're not sure...hope that helps. On 5/30/06, Guilhem Vellut wrote: Hello Doug, I don't have all the elements to solve your problem. When you write "looking through the yaml code it looks like there's an optional options hash", what yaml code are you referring to? And how are you trying to use the method? If you use it in fixtures, the to_yaml method for geometries is used the following way: first: id: 1 data: HELLO WORLD value: 3 geom: <%= Geometry.from_ewkt('POINT(1.4 5.67)').to_yaml %> And it outputs the canonical representation of the geometry for the target database (HexEWKB for PostGIS). guilhem _____ From: georuby-devel-bounces at rubyforge.org [mailto: georuby-devel-bounces at rubyforge.org] On Behalf Of Doug Cole Sent: 31 May 2006 03:26 To: georuby-devel at rubyforge.org Subject: [Georuby-devel] post_gis_adapter's to_yaml function Hello, I just tried to use the to_yaml function in the post_gis_adapter and ran across some problems: -first I got an error related to the number of arguments (1 for 0), looking through the yaml code it looks like there's an optional options hash so I simply redefined the function as "to_yaml( opts = {} )" -after fixing that I recieved the error "wrong argument type String (expected Data) (TypeError)" which I haven't tackled. anyone else run into these problems? I was trying to dump some point data from my postgres database to a fixture for testing. Simply removing the to_yaml definition fixed things, so that's how I've left it, but I thought I'd report the problem. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060531/b2214b0d/attachment.htm From dougcole at gmail.com Wed May 31 14:26:28 2006 From: dougcole at gmail.com (Doug Cole) Date: Wed, 31 May 2006 11:26:28 -0700 Subject: [Georuby-devel] post_gis_adapter's to_yaml function In-Reply-To: <447d4c05.2ed58dcc.0743.fffffe84@mx.gmail.com> References: <7b8d80330605302259x6dc96214gffa72e0182030f36@mail.gmail.com> <447d4c05.2ed58dcc.0743.fffffe84@mx.gmail.com> Message-ID: <7b8d80330605311126s19d6cc2pfe8f4396ce92d9a6@mail.gmail.com> Hmm, you're right, I spoke too soon. According to the documentation to yaml takes a hash of options, so something like .to_yaml( :Indent => 4, :Separator => '') should work, but I just tried it and it didn't so I'm not sure. Since I'm building the entire fixture before using to_yaml, it's not a problem, but I'm not sure of the best way to do it as a single field in a fixture, unless someone else can get .to_yaml to use the options hash. Sorry, Doug On 5/31/06, Guilhem Vellut wrote: > > Well actually, it does not work totally fine when trying to manually > input a geometry in a fixture (with something like <%= Point.from_x_y( > 123.4,567.1).to_yaml %>), using the default "to_yaml" for objects of the > YAML library. The problems are that the document separator ("---") is output > and that the components of the Point are not indented, which makes the YAML > parser crash when reading the fixture. Do you know of options to prevent > that? > > > > Therefore for now I will keep the former to_yaml methods specific to > geometries and rename them "to_fixture_format", so the dumping to YAML > format can work, as well as the input of geometries in a fixture. > > > > guilhem > > > ------------------------------ > > *From:* Doug Cole [mailto:dougcole at gmail.com] > > *Sent:* 31 May 2006 11:00 > *To:* georuby-devel at rubyforge.org > *Cc:* Guilhem Vellut > *Subject:* Re: [Georuby-devel] post_gis_adapter's to_yaml function > > > > Sorry, I should have been more specific. The code I was looking at that > has reference to the optional hash array was the yaml code in the ruby > standard library, where to_yaml is defined for the built in classes > (yaml/rubytypes.rb) Here's a reference to the options hash: > http://yaml4r.sourceforge.net/doc/page/the_options_hash.htm. I was trying > to use the spatial adapter's to_yaml to dump part of my database to a yaml > file, with the ar_fixtures plugin ( > http://nubyonrails.com/articles/2005/12/27/dump-or-slurp-yaml-reference-data) > basically the call boils down to converting an activeRecord's attributes to > yaml ( row.attributes.to_yaml). Like I said, simply removing the to_yaml > function from the postgis_adapter fixed it for me, as yaml defaults to > simply outputting all the instance variables, which works fine in my case. > Doug > > -On a related note - I was reading the archives for this mailing list and > saw that someone was trying to figure out how to get a Geometry column into > their fixture. This is probably too late to help here, but Fixtures are run > through the same interpreter as .rhtml files are so you can always do > something along the lines of #{ Point.from_x_y(x, y).to_yaml} if you're > not sure...hope that helps. > > On 5/30/06, *Guilhem Vellut* wrote: > > Hello Doug, > > > > I don't have all the elements to solve your problem. When you write "looking > through the yaml code it looks like there's an optional options hash", what > yaml code are you referring to? And how are you trying to use the method? > > > > If you use it in fixtures, the to_yaml method for geometries is used the > following way: > > first: > > id: 1 > > data: HELLO WORLD > > value: 3 > > geom: <%= Geometry.from_ewkt('POINT(1.4 5.67)').to_yaml %> > > And it outputs the canonical representation of the geometry for the target > database (HexEWKB for PostGIS). > > > > guilhem > > > > > ------------------------------ > > *From:* georuby-devel-bounces at rubyforge.org [mailto:georuby-devel-bounces at rubyforge.org] > *On Behalf Of *Doug Cole > *Sent:* 31 May 2006 03:26 > *To:* georuby-devel at rubyforge.org > *Subject:* [Georuby-devel] post_gis_adapter's to_yaml function > > > > Hello, > I just tried to use the to_yaml function in the post_gis_adapter and ran > across some problems: > > -first I got an error related to the number of arguments (1 for 0), > looking through the yaml code it looks like there's an optional options hash > so I simply redefined the function as "to_yaml( opts = {} )" > > -after fixing that I recieved the error "wrong argument type String > (expected Data) (TypeError)" which I haven't tackled. > > anyone else run into these problems? I was trying to dump some point data > from my postgres database to a fixture for testing. Simply removing the > to_yaml definition fixed things, so that's how I've left it, but I thought > I'd report the problem. > Doug > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/georuby-devel/attachments/20060531/b210cd17/attachment-0001.htm