[OSM-dev] lua+osm2pgsql=?

Kai Krueger kakrueger at gmail.com
Sat Apr 27 20:49:49 UTC 2013


In response to Richard's suggestion, I hacked up a proof of concept
implementation of a tag filter in lua last week.

Currently it allows you to write a filter function (one for nodes, one for
ways and one for relations) in lua that takes in a set of tags and returns a
(potentially) transformed set of tags and a boolean flag, if the object
should be processed further. For ways, it also determines if it should be
treated as a line or polygon.  This should allow for things like normalising
the data from "oneway=yes/1/true" or rewriting things like "highway=footway"
into "highway=path, foot=designated", which could hopefully simplify this
processing out of the mapnik stylesheets.  

The current proof of concept implementation only works for the rendering
output so far, not the gazeteer output.

The question now is what to do with this? Is there enough interest for it to
be worth cleaning it up and committing it? Should it replace the current C
filters, or be an additional option? How much performance hit is acceptable
for it to become the default option? Should it not be committed in this form
and rather worked on a more generic solution to include the gazeteer
backend?
Are there other things that would be good to be able to script outside of
the source code with lua? How does it interact with the current styling of
the columns in the osm2pgsql schema? 

For anyone interested, they can find the current patch at
http://pastebin.com/Jrh9tA8i

Kai
 

Richard Fairhurst wrote
> One of the many wondrous things about OSRM is that you handle the speed 
> impact of different tags (e.g. highway=motorway vs highway=unclassified) 
> with plugins written in Lua, a fast but easy-to-understand scripting 
> language.
> 
> Wouldn't it be great to have the same capability in osm2pgsql?
> 
> Think: path rendering. Right now, you have to potentially weigh up 
> highway=, access=, bicycle/foot/horse/etc.=, designation, and surface= 
> tags. That's a whole bunch of Mapnik rules (or whatever) - slow to 
> write, slow to run. Remapping the tags on database import with osm2pgsql 
> would fix this.
> 
> Adding this to osm2pgsql is way beyond my poor brane, I'm afraid, though 
> I'd love to do it. But it would make a great GSoC project:
> 
> http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2013/Project_Ideas#Data_processing
> 
> or maybe someone might feel inspired to just code it. ;)
> 
> (Thanks to lonvia and Gnonthgol in #osm-dev for suggestions leading to 
> this!)
> 
> cheers
> Richard
> 
> 
> _______________________________________________
> dev mailing list

> dev@

> http://lists.openstreetmap.org/listinfo/dev





--
View this message in context: http://gis.19327.n5.nabble.com/lua-osm2pgsql-tp5757509p5758794.html
Sent from the Developer Discussion mailing list archive at Nabble.com.



More information about the dev mailing list