site=parking relation is not renderend

[richardbrinkman]

In may 2011 a new relation (type=site, site=parking) has been approved on openstreetmap for tagging detailed parking areas. However, currently they are not being rendered in the mapnik style. Is it possible to add rendering of this relation. The original proposal gives a suggestion on how it should look like.

[matkoniecz]

Used less than 3000 times ( http://taginfo.openstreetmap.org/tags/site=parking ) compared to over 1750 000 uses of amenity=parking.

I am not sure is it even possible to use this data, even assuming that relevant tags are available in the database.

[matkoniecz]

Also after reading liked page and http://wiki.openstreetmap.org/wiki/Relation:site I am not sure how this tagging scheme is supposed to be used.

I think that decent documentation of the tagging scheme should be available before even considering rendering it. Especially as it includes relations.

[imagico]

This seems to be about two things:

• rendering amenity=parking_space at very high zooms - this could be worth considering, there are 69000 uses.
• rendering relations type=site, site=parking with an icon/label. Since relations type=site do not have a defined geometry (unlike multipolygon relations) there does not seem to be a general way to determine an icon/label position for such a relation.

Side note: the tagging scheme is kind of strange since there is the well established amenity=parking and having a site relation for a parking in addition violates One feature, one OSM element unless it is meant to replace the established tagging amenity=parking.

[richardbrinkman]

A likely reason why the tagging site=parking is used less often than amenity=parking is that it's not rendered. Tagging each and every parking space and grouping them together in a relation is quite some work. Most people will not take the effort, since it's not rendered anyhow.

It's similar to the egg/chicken problem. No rendering support means no tagging and vice-versa.

In the current situation, improvements in the database lead to worsening of the maps.

In the ideal situation the amenity=parking_space (currently not rendered at all) should be rendered with the same yellow surface as amenity=parking (but without the blue P). The site=parking should print the blue P (with the name beneath in the appropriate zoom levels) somewhere in the center of all the elements of the relation.

[matkoniecz]

unless it is meant to replace the established tagging amenity=parking

See "This new tagging scheme is not meant to replace amenity=parking" at http://wiki.openstreetmap.org/wiki/Proposed_features/parking

[richardbrinkman]

Which means that amenity=parking and site=parking can co-exist together. You can choose which one to use for a particular area. But not use them both for the same thing.

It's similar to multipolygon relations and landuse=forrest, for example. Either you draw an area which you tag as landuse=forrest OR you create a multipolygon relation collecting all outer and inner ways and tag the relation with the landuse. The multipolygon relation is not meant to replace the area, but are both being rendered.

[imagico]

No, that's two completely different things - closed ways and multipolygon relations can universally be used interchangeably in OSM.

The site=parking should print the blue P (with the name beneath in the appropriate zoom levels) somewhere in the center of all the elements of the relation.

Which could frequently be located outside the parking.

[richardbrinkman]

Which could frequently be located outside the parking.

True, but the same holds for names of irregular shaped buildings, countries or any area or multi polygon relation. Perhaps the best way for the placement of the P is to use the same rules as used for the placement of names on multipolygon relations with several disjoint areas.

[imagico]

Multipolygons can be and are labeled in a way that ensures the label center is positioned inside the polygon. You can't do that for site relations since they do not have a defined inside and outside.

[richardbrinkman]

Not all multipolygons have a node with role "label". From the wiki:

If the label role is present, then place the label at the location of that node. If more than one label node exists (e.g. a very large site), then place labels at each node as the zoom level allows. If no label node exists then use the centroid of the perimeter area. Failing that, use the centroid of all member objects.

In case of a site=parking there is no node with label role, so the P (and name) should, according to the wiki, be placed at the centroid of the perimeter area or (failing that) at the centroid of all it's members.

[gravitystorm]

That guidance on the wiki is not helpful or even thought through - and in fact by being there and being wrong, it's actually unhelpful. Let's not refer to it, please.

[kocio-pl]

If the Wiki is wrong or not clear enough somewhere, I think we should first let people on Tagging list know about the problem, not just avoid it. It's unreasonable to expect it will get better without feedback and Wiki is our main source of tagging knowledge.

[SomeoneElseOSM]

(not directly related to this issue but) for info I've tidied http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Rendering a bit to fit more in line with my experience, though not touched other iffy parts of that page.

[pnorman]

Wiki is our main source of tagging knowledge

Not particularly. The wiki is one of many sources of tagging practice, and the ultimate authority is the database itself.

As Andy has said, we shouldn't be referring to the wiki in its current state.

Not all multipolygons have a node with role "label"

We do not and will not be using label nodes, nor is that what @imagico was talking about, he was talking about label placement.

Perhaps the best way for the placement of the P is to use the same rules as used for the placement of names on multipolygon relations with several disjoint areas.

The wiki doesn't define rules for how we label. First, the wiki can offer guidance, but not binding rules for data consumers. Second, multipolygons with disjoint areas are converted into multiple POLYGONs in the database.

---

In any case, this tag isn't currently suitable for rendering for a few reasons

• It's not in our database
• It's not likely to be in our database
• It doesn't seem to be designed in a manner where it can be rendered
• It doesn't have wide geographic usage
• 3-5 users are responsible for most occurances
• It only has 2.5k uses.

[imagico]

You could leave it open for amenity=parking_space which is a reasonable suggestion for the highest zooms.

[kocio-pl]

Not particularly. The wiki is one of many sources of tagging practice, and the ultimate authority is the database itself.

As database contains no definitions, it's even more just the source of tagging practice (strictly, because there's no theory at all). But that's just wording and I wouldn't make it big - this way or another Wiki is important and Tagging list is probably the best place to correct any mistakes or omissions in tagging.

[dieterdreist]

sent from a phone

Am 22.07.2015 um 20:14 schrieb Paul Norman notifications@github.com:

Not particularly. The wiki is one of many sources of tagging practice, and the ultimate authority is the database itself.

the wiki explains the meaning of a tag. In the database it is very hard to understand the meaning. Ultimately you would have to look at the tags, then visit the places with the tag in the real world and then come up with a theory what the meaning of the tag might be, considering that some applications of the tag might be off the general consensus and some tags might have different meanings in different regions. Hm, doesn't sound like the database will help us a lot in understanding the tags.

cheers
Martin

[pnorman]

You could leave it open for amenity=parking_space

This issue is about the relation. amenity=parking_space could be implemented independently, and already has #428 for it. #776 has some more information.

[kocio-pl]

What are the main problems with Wiki and where exactly they are? Is it multipolygon or site relation which is unhelpful or maybe some other definition?

[matkoniecz]

http://wiki.openstreetmap.org/wiki/Relation:site is not explaining how it is supposed to be used. Following http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site#Rendering would result in a bad results. Especially "label node" is a blatant mapping for renderer.

[jdhoek]

With #3092 merged, can this issue perhaps be reopened? In the approved feature proposal a suggestion for rendering these relations is given. It would provide some amount of rendering parity with amenity=parking.

Are there technical barriers remaining to rendering an icon somewhere for these parking site relations?

[SomeoneElseOSM]

@jdhoek I can't comment with respect to this map style, but I did look at rendering site relations in a different style a while back and couldn't see any reasonable way of doing so (I've no idea what you could do with this for example). If you can, pull requests welcome at the constituent parts described here.

[matkoniecz]

@jdhoek Parkings simply composed from areas can and should be mapped as multipolygons.

I see no reasonable way to render parkings not composed from areas like https://www.openstreetmap.org/relation/8138564 (even as a human I have no idea what is it supposed to represent - I suspect mistagged amenity=parking_entrance)

[kocio-pl]

No matter what we think about relation rendering, there's probably a technical problem, which currently does not allow it: osm2pgsql-dev/osm2pgsql#230 (comment).

[jdhoek]

Thanks for the explanations.

[kocio-pl]

However I'm not sure how do we show names for example for nature reserves tagged as the relation - does anybody know it?

[matkoniecz]

nature reserves tagged as the relation

osm2pgsql generates areas from mutipolygons and closed ways (with certain tags)