Added conversion for custom field names and coordinate systems

[matt-baker]

Hi again. For your consideration...

This allows postgis-preview to work against databases that do not use 'geom' as the field name for the geometry or that do not use lat/lon (4326) for the coordinate system.

A summary of the changes:

• config.json - minor changes to the structure of the data and two fields added. The fields are 1) dataCoordinateSystem - the coordinate system of the table date, and 2) geomFieldNames - an array of field names that can be converted to 'geom'
• dataCoordinateSystem could be boolean, but perhaps it would be useful at some point to know the native coordinate system?
• I used an array for geomFieldNames because some of us are lucky enough to have inherited systems that use multiple names for the geometry field.
• server.js - the DB config looks for config['database'] instead of just config and string manipulation is used to convert custom field names (SELECT some_name becomes SELECT some_name as geom) or convert data to 4326 using ST_Transform (SELECT ST_Transform(the_geom, 4326) as geom)

The biggest advantage is that end users can query using their native field names and do not need to worry about converting to 4326. For example:

A user can use:

SELECT pt_geom, address, count(*) FROM table...

instead of having to type the following:

SELECT ST_Transform(pt_geom, 4326) as geom, address, count(*) FROM table...

It's a very minor and subtle difference, but I figured it might be useful for others who are stuck with legacy systems and want to provide this to end users who may find coordinate systems etc confusing.

This was just a quick fix I put up at work today and I'm relatively new to NodeJS so suspect there is probably a better way of doing this!

Thanks.

[chriswhong]

I like it! Two thoughts:

1 - I wonder if manipulating the SQL query itself is adding a complexity/a point of failure, it just feels wrong to not send whatever the user entered to the database. I am wondering if it makes any sense at all to manipulate the results in JS (perhaps with proj4js) before sending them to dbgeo instead of adding an ST_Transform() behind the scenes.

2 - dbgeo has an option for the name of the geometry column, so it's possible to allow for alternate geometry column names without having manipulate the SQL query.

One annoyance of CartoDB is that the_geom_webmercator must exist in your result set in order for rendering to work, so I really like the idea of allowing configuration to specify your geom name so you can just write queries however you are used to writing them.

Thoughts?

[matt-baker]

I never saw the notification about your reply - sorry for the delay! I do agree that manipulating the user input can be a bit tricky. Would the JS manipulation make a suggestion as the user enters it? Either way works - the only advantage I can think of is that if a user is savvy enough to understand what the JS manipulation is doing then hopefully they would be able to just enter the correct SQL. Re dbgeo - that sounds like a much cleaner approach.

[chriswhong]

Would the JS manipulation make a suggestion as the user enters it?

I think it just happens behind the scenes if an alternate SRID is specified in the config file (what I mean is that postgis-preview would only work with a single SRID, and you would need to change the config file to get it to work with a different one. In my case, all of my tables have the same SRID and geom column name, but if you are mixing several in the same database I can see how this would get tricky)

Either way I think the user has options... either adjust your queries to fit the default rendering requirements ("geom" and 4326) OR adjust config to specify rendering requirements.

[matt-baker]

Sounds good to me. We unfortunately have mixed SRIDs (4326 and UTM/26915) but this is probably (hopefully?!) an unusual use case where users can be trained.