Relation with parking, not on map.

[AllroadsNL]

A relation with parking not rendered on map. Two parking area, should have one icon P for parking. Also expected a yellow color parking.

According to this approved proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/parking#Site_relation

required type site
required site parking Please note, that at the time of voting, the proposal for site relations didn't have a clear definition on how to use the site key. To be on the safe side, please add both tags: site=parking and amenity=parking

Relation: type=site site=parking even with the extra amenity=parking, what should not be necessary, it would not render.

Solution for decreasing a lot of icons P on the map.

Example: changeset: https://www.openstreetmap.org/changeset/36846260 relatie: https://www.openstreetmap.org/relation/5912895 individual ways have no tags.

Could this be rendered?

[simonpoole]

site relations are currently not supported, while that might be a "good idea" it will likely have to wait for the big re-import/schema change.

[AllroadsNL]

And when is that planned?

[matkoniecz]

For start - is it necessary to support site relations?

For example https://www.openstreetmap.org/relation/5912895#map=19/52.59480/6.10410 may be mapped as a standard multipolygon.

site relations are currently not supported, while that might be a "good idea" it will likely have to wait for the big re-import/schema change.

Supporting site relations would require even bigger change. Either change in https://github.com/openstreetmap/osm2pgsql or replacement of osm2pgsql by something else.

[Circeus]

As I understand and use them, site relations are a strictly semantic connection, not meant to be rendered anyway, at least in the main map.

Furthermore, you are misunderstanding that site=parking proposal. The rendering is clearly not intended to be "unloaded" on the relationship: your areas are still supposed to be tagged with parking or parking_space!

[AllroadsNL]

For me, that's a 180 degree turn. If it was to be rendered or "unloaded" why is it written

To be on the safe side, please add both tags: site=parking and amenity=parking

For me this means, that it is placed on the relation. To be sure it is rendered well. And not on the area way.

Relation and multipolygon is not mentioned in the wiki.

Under advantages: http://wiki.openstreetmap.org/wiki/Proposed_features/parking#Advantages In this page only site as relation is mentioned, and it is approved. Meaning it must only be implemented.

Renderers could use the information in the relations to choose a suitable name for the different zoom levels in their maps. It should also help reduce the clutter of to many "P" symbols on the map.

So, no amenity=parking on the area. Only on relation. Not both.

[mboeringa]

So, no amenity=parking on the area. Only on relation. Not both.

Your best bet at this point in time is creating a multipolygon, and adding all parking areas to this. Implementing site relations and other, possibly mixed geometry type, super relations in renderers is NOT trivial. In many cases, it requires significant changes to multiple tools part of the rendering chain of programs. This is a big thing.

Multipolygon relations are already supported by multiple applications. And properly implementing these was not trivial either for many of these development projects. In fact, processing them also involves custom decisions for each program and dealing with some ambiguities (e.g. how to handle "old-style" multipolygons), meaning different implementations are not necessarily 100% compatible in their final result.

[matkoniecz]

Relation and multipolygon is not mentioned in the wiki.

http://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dparking&diff=1267228&oldid=1232422 - hopefully it will make documentation more clear.

Also, this ticket is duplicate of #1678

[simonpoole]

@Circeus I don't think that anybody ever implied that site relations should not be rendered, actually if we could do so a lot of the map clutter and labeling issues would go away. But as has already been said, a) it would need at least a non-trivial amount of work, and b) can't be done right now in any case.

[AllroadsNL]

The advice is given make it a multipolygon.

I changed the above example to multipolygon. https://www.openstreetmap.org/relation/5912895 give both area the role outer

But now after several day's nothing show up at the map. What is wrong? Tried to search for equal places with two area as 1 parking with 1 P icon could not find them. http://overpass-turbo.eu/s/e5x Mostly used by a area in area situations. And I see often that both is given amenity=parking way/realation, so this given multiple P icons and that is what I do not want.

[mboeringa]

Multipolygons are not processed instantly like plain nodes and ways, as they need special processing, it can take time, sometimes considerable, for them to show up in the rendering.

And I see often that both is given amenity=parking way/realation, so this given multiple P icons and that is what I do not want.

You mean both the way and the relation are tagged with amenity=parking? That is bad tagging, tags should only be on the relation, remove them from the ways in case you encounter such examples.

A properly defined multipolygon should only show a single icon (at least if openstreetmap-carto has proper labelling settings for this and doesn't label the individual parts).

[pnorman]

Multipolygons are not processed instantly like plain nodes and ways, as they need special processing, it can take time, sometimes considerable, for them to show up in the rendering.

This is wrong. Multipolygons are handled with diff updates at the same frequency as other updates. They happen towards the end of a particular update, but this is seconds later, not considerable time.

What is wrong?

Probably something update related to openstreetmap/osm2pgsql#67

This is also drifting off-topic for the original question of rendering site relations.

[mboeringa]

This is wrong. Multipolygons are handled with diff updates at the same frequency as other updates. They happen towards the end of a particular update, but this is seconds later, not considerable time.

OK, thanks for correcting. One of those OSM myths I shouldn't have repeated and I think I got confused with the coastline process...

[dieterdreist]

sent from a phone

Am 01.02.2016 um 19:25 schrieb mboeringa notifications@github.com:

This is wrong. Multipolygons are handled with diff updates at the same frequency as other updates. They happen towards the end of a particular update, but this is seconds later, not considerable time.

OK, thanks for correcting. One of those OSM myths I shouldn't have repeated and I think I got confused with the coastline process...

IIRR there was once a problem with changed relations not triggering tile invalidation if none of the members changed, try moving a node very little or add some detail on the tile