-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plan database re-import #1504
Comments
@pnorman @gravitystorm Could you have a look what else should be added to this issue? |
This is already quite a big project, and it lingers already for quite some time. Would it be an option to only enable hstore in the first database reload, and drop the columns that have become spurious due to hstore only in the second database reload (in 6-12 months)? I think that would also make things operationally much simpler, because we wouldn't need to coordinate the database reload and the stylesheet rollout that tightly. As I said, it's quite a big project given the amount of developer time, and I'm afraid that if we want to do too much as the same time, we will keep pushing this issue forward forever. On the other hand, the performance benefit would be very welcome. |
Just for clarification - hstore will allow later use of keys that were not originally on the list? Otherwise a larger scale brainstorming on what important keys are currently missing would be in order. And it's leaf_type, not leaftype by the way. |
Yes, but only for objects that have another key that is in the list. For example, if we have an object with man_made=pipeline and location=underground, we would be able to access underground even though underground is not in the list. However, we wouldn't be able to access an object only tagged emergency=ambulance_station if emergency is not in the list.
Yes, I think we should have a larger scale brainstorming anyway (but hstore should reduce the number of tags that we need).
Thanks, corrected, things seem to have changed since the issue was created. |
Ok - so the most important thing is to have all primary keys on the list while secondary keys can also be used ad hoc later if the object has a known primary key. What comes to mind is Other primary keys that are fairly widespread in use and could be considered for rendering are:
For secondary keys i would have |
I've gotten most of the way through the style file converting to hstore, so I should soon be able to start seeing what columns shouldn't be in hstore. |
That's good news! Any work in progress you can show? |
Pushed my dev branch up to https://github.com/pnorman/openstreetmap-carto/tree/hstore |
Great work! It looks indeed like most work on rewriting the queries has been done. Would it be easy to convert the data from the .style file to the .lua file? I saw that you dropped for example aerialway from the .style file. Just to check my understanding, I suppose you'll need to add it back at a later point? |
That's the unknown. There is no need to have any columns for specific tags, as anything not in a column is in with hstore. That doesn't mean it's a good idea. For some, for example amenity, landuse, highway, natural, and building, it is almost certainly a good idea to have them as a column. To my knowledge, no one has done any rigorous testing of what should and should not be a column. That's my intent. |
I'm still a bit confused about it all. How will osm2pgsql know whether to add an object with an aerialway as a row to the database? Currently we filter out objects that do not have any of the keys in the list of keys. Will this remain the case? If so, how does osm2pgsql know not to filter out aerialways if there is no aerialway in the list of keys?
Do I understand it correctly that this is incorrect? |
Yes, the statement you quoted is incorrect. For this part of SQL rewrites I am importing with https://github.com/openstreetmap/osm2pgsql/blob/master/docs/usage.md#hstore might help explain the options a bit better. We would not be using Previous research showed
.style development is one of the limited situations where |
Thanks for the clarification, I updated the first post. We should still decide if there are keys / values for which we want to change whether closed lines are interpreted as polygon or linestring, right? |
Tag toilets:disposal would be nice, so that the option exists to render flush toilets differently from chemical and pit toilets. #1508 drinking_water or drinking_water=no would also be good, to render campgrounds and huts with no water with a modified symbol indicating the lack of water. denotation may be there already. If not, it lets you render prominent trees more, um, prominently. |
I think that more prominent rendering for named trees would be enough. I also see a problem with that tag (see http://wiki.openstreetmap.org/wiki/Talk:Key:denotation ). |
As @pnorman has explained, the discussion of which tags to "add" is unnecessary, so lets not spend time on it. All features will appear when we use |
@gravitystorm even on review, the above discussion does not clearly reflect the magnitude of this shift, especially given the long history of the database limitations. Could you confirm:
|
@brycenesbitt the best person to ask these questions to is @pnorman. |
+1, it's great to have this, it will help you all a lot. This is what I already have available to me for my personal renderer in development (thanks to ESRI implementing it's own key/value storage for OSM based data).
Ultimately, @pnorman indeed may answer best, but from what I know and read, I think these are all sound conclusions... |
:-) |
As a mild reminder, this of course does not solve the true "cartographic" problems of how to cope with, and display, all of this data at various scales... that will still require thorough human evaluation and consideration (not even taking into account possible technical challenges when more features are going to be rendered). But that should certainly not withhold on implementing this in any way as @gravitystorm already pointed out ;-) |
9 tags left in my conversion, then I can start benchmarking. There's a bunch of SQL cleanups I want to do to master once we've worked out the .style file and before a more precise conversion. |
Are there any news of progress or outstanding problems regarding database re-import? |
We specifically want to avoid the situation where closing a loop changes semantics. We'd have to look at what tags indicate areas and what don't, not what keys. |
Another thing regarding the re-import i forgot but remembered when reading #2108 (comment) - would it be possible to have non-polygon relations in the database somehow, in particular route and site relations of course. The elegant way to represent them would be to have a separate relation table and an incidence table indicating memberships and roles. Another option would be representing them as GeometryCollection. I suppose this is all difficult due to lack of support in osm2pgsql currently but i wanted to bring it up none the less. |
The pgsql backend has four tables.
We currently have route relations, and should continue to have them. But I doubt we've tested that. |
The current way route relations are supported is not really great since it lacks membership information. See also #596. I guess the same problem would apply when representing relations in general as GeometryCollection. But i see this is more an osm2pgsql issue and not really specific to this style. |
For rendering capitals from relations membership information would also be needed (#2365). |
Yep - different ways of processing relations or anything involving membership information is outside the scope of what we can do in the style. |
On http://lua.osm-carto.paulnorman.ca/#8/49.178/6.803 I see something called "Deutschland - Luxembourg / Luxemburg / Lëtzebuerg" (overpass) rendered. Probably the relation of type=multilinestring (1628284). |
Below z10 the lua branch paints railways over roads, resulting in blacker roads (location on osm.org) |
Does that mean we can finally get |
It's not that relation. I wouldn't expect it to be in the DB, but I checked, and it's not in any of the tables. It looks to be this relation
So a multipolygon handling issue. |
https://lua.osm-carto.paulnorman.ca/ moved to HTTPS and HTTP/2 - loading should be much faster now, and generally on par with osm.org, or faster given my low load.
This is a bit of a strange one, but I see what's happening. osm2pgsql's C transform z_order puts railways between tertiary and secondary, while the lua transforms use the z_order we use at higher zooms, putting railways above all highways. This runs into the problem that there is no universal z_order. For another style I put railways into the ::casing attachment on low zooms to have road fillls drawn above them and into the ::fill attachment to have rails on top of everything at high zooms. We could
I'm inclined towards 1 i for now and then look at 1 ii later. 3 is something we can do post-merge without a major version upgrade, because removing a column is possible without a reload. cc @math1985 |
This will be technically possible then, yes. |
relation 5372584 is another case, but I think the first is easier to debug. |
The MP problem appears to be in For an example, see require ("openstreetmap-carto")
_, _, ms, _, _, _ filter_tags_relation_member({type="multipolygon", landuse="forest"}, {{}}, {}, 1)
for k, v in pairs( m ) do
print(k, v)
end Output is
I'm going to be looking into this for ClearTables with the issue https://phabricator.wikimedia.org/T153799 and hope to reuse tests for here |
I've reloaded https://lua.osm-carto.paulnorman.ca/ to use the latest code, the above problems with MPs are fixed, but it's possible it's introduced new ones. |
How does this affect adding differential data to the database? For example, what happens when a user changes an old-style multipolygon to a new-style one, and this change is appended with osm2pgsql? |
Diffs go through the transforms, just like initial imports. The contents of the rendering tables should be the same regardless of if it was an initial import + diffs, or a reimport of new data. |
This sounds non-trivial to me (both in the old and new situation). What if only an outer element is changed, will the multipolygon be processed again as well? Will all elements be processed again if a tag on the multipolygon is changed? I see tens of ways this could be going wrong. |
The ways this could go wrong are the exact same ways that could go wrong with the C tag transforms - a relation is modified, a way is modified, or both are modified. |
I looked out for some differences and here's what I found:
|
Am i correct that the data is a few days old? leisure=track is ignored if not on an multipolygon (ref #2238): An open way leisure=track https://www.openstreetmap.org/way/144179903 is not rendered at all. The closed way leisure=track https://www.openstreetmap.org/way/388151425 is also not rendered. As this has no area tag i expected a loop (was an area on master branch). |
In master with relation 6267039 there are about a dozen POLYGONs, all completely independent, and in lua there is one MULTIPOLYGON. This means that there's only one feature to render or not, as opposed to a dozen disjoint areas. |
This is a management issue for the upcoming re-import of the database. A re-import of the database gives us the opportunity to change the keys that are available to the stylesheet.
We will use the lua tag transformation option from osm2pgsql, and enable the hstore option.
Questions to be answered
Action plan
Requested changes
The following changes have been requested:
Keys to be added
Adding hstore will avoid the need to manually add these keys.
Keys to be added
Adding hstore will avoid the need to manually add these keys.
Keys to be treated as linestring
Keys to be treated as polygon
Key/value combinations to be treated as linestring
Pull request written, see osm2pgsql-dev/osm2pgsql#346.
Key/value combinations to be treated as polygon
Pull request written, see osm2pgsql-dev/osm2pgsql#346.
Also include as way
This has already been fixed in the current default lua style file.
The text was updated successfully, but these errors were encountered: