Add rendering for parking_entrance rendering

[ashh87]

I was looking at KeepRight and came across this error and the one next to it:

http://keepright.at/report_map.php?schema=86&error=48351546

These nodes are the entrance and exit to an underground car park. I tried to fix this by changing the nodes from amenity=parking to amenity=parking_entrance (http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_entrance) and adding entrance tags to both. I've also suggested to KeepRight that oneway ways which end/start with nodes tagged with entrance=* be not flagged as errors.

Because I've changed the OSM data, it would be good if these nodes were still rendered as parking, so this pull request adds a new symbol (as suggested on the above OSM wiki link) and instructions to render this on the 'main' entrance. Of course, this could be extended to include private parking entrances in a different colour, etc. The pull request currently has no icon for exits - having separate entrance/exit/both(?) signs is a bit more complicated, especially when you come to render the name tag, so more complex tagging might be needed. (name for entrance=main is rendered, but this doesn't necessarily mean the entrance is not an exit ...)

[matkoniecz]

I think it would be preferable to not display private parking entrances.

[ashh87]

It might well be a bit much to show a sign for all private car parks. I don't think the filter can be the same as the existing private filter though, because this tag would typically cover entrances to parking which belonged to shop/attraction, so should probably be tagged access=destination. The current filters on amenity=parking would display the private parking symbol, but on amenity=parking_entrance, where there is no private symbol, we perhaps need to be more careful about when not to display an icon.

With reference to http://wiki.openstreetmap.org/wiki/Access - should we only show an icon for access=customer,access=customers,access=destination,access=yes,access=public,access='' - which would lead to all other values of access not displaying an icon. This still allows parking entrances you might actually want to go to if you are going somewhere to be displayed, whilst making sure people's garages, if they're tagged at all, aren't.

[matkoniecz]

Also access=permissive should be displayed.

[dieterdreist]

2014-05-09 16:38 GMT+02:00 ashh87 notifications@github.com:

With reference to http://wiki.openstreetmap.org/wiki/Access - should we
only show an icon for
access=customer,access=customers,access=destination,access=yes,access=public,access=''

• which would lead to all other values of access not displaying an icon.

+1 (including permissive), an icon is really not needed for private
parkings which are not accessible (although it is perfectly fine to draw a
polygon for them if the parking area is mapped, they can be really big,
think of the parkings for factory workers or huge offices / corporation
headquarters). I wouldn't render access=customer, the value customers is
used almost 20 times, and rendering only one would help to normalize.

looking at http://taginfo.openstreetmap.org/keys/access#values
there are a few other values that might be considered (didn't check for
overlap with parking):
delivery
designated
official

[matkoniecz]

Note that access=designated, access=official may be used but make no sense as it is not defined what is designated/official. This values may be used for something specific (like bicycle=designated).

I am unsure about access=delivery, but I would be rather against as it is not available to typical person.

[matkoniecz]

I am against including "public", it is rare (13:388) synonym of "yes", not documented on wiki.

[ashh87]

With access=public, I would include it to be consistent with the equivalent access rules for amenity=parking ([access != ''][access != 'public'][access != 'yes']), and change both at the same time if 'public' isn't wanted? I think I am also against access=delivery.

access=customers only is fair, but maybe a bot should change all 'customer' to 'customers'? Also, this tag/value is, afaics, still a proposal, even though it is used and listed on the wiki - does this make a difference?

Finally, I can't make TileMill work by specifying "[access = '']". "[access != '']" works as expected. Cheating slightly and using "[access =~ '^$']" also seems to work. Is this a bug with TileMill or am I trying to match an empty string wrong? What effect does this have on mapnik?

[ashh87]

OK, having found the correct syntax, I've added access filters.

@mkoniecz I can remove [access='public'] in another commit, and remove the same on the existing parking rule at the same time for consistency?

I can also add a commit to change all "!= ''" to "!= null", as suggested here:

https://github.com/mapbox/tilemill/issues/2319

But I think that's a separate issue, so perhaps a separate pull request.

[matkoniecz]

@ashh87 Yeah, public is apparently a separate issue. Probably the best way it to handle it as a separate issue, ask before this on mailing list whatever there is any difference (I did this just now) and (assuming that there is no difference), remove it from JOSM presets and add to JOSM validator changing access=public to access yes.

So public should appear here for consistency.

[matkoniecz]

Also, is it possible to keep P the same as in normal parking, just with roof?

https://github.com/ashh87/openstreetmap-carto/blob/master/symbols/parking.p.16.png
https://github.com/ashh87/openstreetmap-carto/blob/master/symbols/parking_entrance.p.16.png

Parking entrance P is lower and significantly thinner.

[ashh87]

I created a new one directly from the existing P png symbol rather than the reference suggested svg for parking_entrance. Hopefully that looks better?

[matkoniecz]

Yes, IMHO it is much better.

[ashh87]

Could you link to your forum post about access=public please? I couldn't see it on the osm forums, so not sure where you posted :) Is this in a mergeable state or do we need to hold off for now?

[matkoniecz]

about access=public:

https://lists.openstreetmap.org/pipermail/tagging/2014-May/017501.html
https://lists.openstreetmap.org/pipermail/tagging/2014-May/017509.html
https://lists.openstreetmap.org/pipermail/tagging/2014-May/017510.html

http://josm.openstreetmap.de/ticket/10007#ticket

Note that I have no rights here to accept pull requests.

[matthijsmelissen]

Merges are done by @gravitystorm, and I haven't seen him around for a while. He might be on vacation or so.

[matthijsmelissen]

I don't think this does what it is supposed to do. If I look at the code, it seems that all entrances will be rendered, not only parking entrances. An entrance selector nested within a parking selector does not select entrances within parkings. Can someone confirm?

[ashh87]

If that is the case, surely the pre-existing rule above it:

[amenity = 'parking'][zoom >= 15]::amenity {
point-file: url('symbols/parking.p.16.png');
point-placement: interior;
[access != ''][access != 'public'][access != 'yes'] {
point-file: url('symbols/parking_private.p.16.png');
}
}

would render all private access nodes as private parking spaces (if they are not later matched by another rule...). This is the rule I based my patch on, making the assumption that the above rule first matches parking, then from that set, matches access. With this assumption, I simply changed the conditions slightly...

Or have I misunderstood :S

[matthijsmelissen]

No, my fault. For some reason, I read [amenity = 'parking_entrance'] as [amenity = 'parking']. Please ignore my previous comment. :)

[matthijsmelissen]

Note that this pull request contains a change in the osm2pgsql style file, and therefore requires a reload of the database. We will therefore wait with merging this pull request until the next database reload.

[ashh87]

project.mml has changed so much... how should this now be updated? I was going to fix the merge conflicts but I'm not sure how to do that now :S

[matkoniecz]

see "editing layers" in https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md

[ashh87]

Thanks. Updated, ready for merge again and passing CI.

[matthijsmelissen]

Unfortunately this PR got outdated in the meanwhile. We also still cannot merge it, unfortunately, due to entrance tag lacking in the database. Thanks for the PR though!