It may be worth looking at SomeoneElse’s LUA script for inspiration: it’s a very rich source for ways to process a wide range of things using LUA & osm2pgsql. I suspect that pre-processing names in LUA might be easier than writing stored procedures. There is also the use of a relatively simple polygon to process specific name rules (in this case preferring name:cy in areas with >40% Welsh speakers), which may be relevant to Nepal.
I guess the trade off is time spent loading the database if you decide to change the LUA script versus time rendering a map if you do the logic in a Postgresql stored function.
I used to have a pretty custom osm2pgsql.style and found it a pain if I wanted to use a “new to me” tag. So I have recently gone to using the tags hstore for accessing things not in the default osm2pgsql.style. That allows a bit faster turn around time if I want to test some new rendering.
But maybe once I’ve settled in on a way to handle tags it might be worth moving the logic from the mapnik XML style and/or Postgresql stored function to a LUA script to speed up production of final PDF print maps.
I think you can still use hstore & have the best of both worlds. Another trick I use is to load into tables not using planet_osm_ and create views with the default names which allows a fair amount of additional jiggery-pokery (but I more of less learnt SQL by writing huge views because the software I worked with could only cope with 1 SQL statement at a time & DBAs were OK with views but more or less nothing else).
OpenStreetMap
Discussion
Comment from SK53 on 28 December 2019 at 10:25
It may be worth looking at SomeoneElse’s LUA script for inspiration: it’s a very rich source for ways to process a wide range of things using LUA & osm2pgsql. I suspect that pre-processing names in LUA might be easier than writing stored procedures. There is also the use of a relatively simple polygon to process specific name rules (in this case preferring name:cy in areas with >40% Welsh speakers), which may be relevant to Nepal.
Comment from n76 on 28 December 2019 at 13:38
I guess the trade off is time spent loading the database if you decide to change the LUA script versus time rendering a map if you do the logic in a Postgresql stored function.
I used to have a pretty custom osm2pgsql.style and found it a pain if I wanted to use a “new to me” tag. So I have recently gone to using the tags hstore for accessing things not in the default osm2pgsql.style. That allows a bit faster turn around time if I want to test some new rendering.
But maybe once I’ve settled in on a way to handle tags it might be worth moving the logic from the mapnik XML style and/or Postgresql stored function to a LUA script to speed up production of final PDF print maps.
Comment from SK53 on 28 December 2019 at 15:29
I think you can still use hstore & have the best of both worlds. Another trick I use is to load into tables not using planet_osm_ and create views with the default names which allows a fair amount of additional jiggery-pokery (but I more of less learnt SQL by writing huge views because the software I worked with could only cope with 1 SQL statement at a time & DBAs were OK with views but more or less nothing else).
Comment from Harry Wood on 30 December 2019 at 22:35
I see you’ve blogged a fair bit about OpenStreetMap. We could add your blog, or just the OpenStreetMap category: https://retiredtechie.fitchfamily.org/category/openstreetmap/ to http://blogs.openstreetmap.org if you fancy it!
Comment from n76 on 30 December 2019 at 22:42
Sure. I am unaware of the mechanism for adding https://retiredtechie.fitchfamily.org/category/openstreetmap/ to http://blogs.openstreetmap.org so someone else would have to do it.
But I have no objections. I’ll just have to remember that if I categorize something as OpenStreetMap it will automatically show up elsewhere.