[Tagging] Feature Proposal - Voting - parking (redux)
dieterdreist at gmail.com
Mon Apr 18 13:05:44 BST 2011
2011/4/17 Flaimo <flaimo at gmail.com>:
> since no new input came in over the last week after my second RFC
> mail, i started the voting phase for
OK, this looks almost nice now ;-)
Stil some definitions could be cleaner:
Why do you not want all entrances of parkings to be mapped as
amenity=parking_entrace, but rather reduce it's use to "Entrances to
underground or multi-storey parking facilities, in case their physical
presence can’t be fully mapped."
I don't see why the entrance of a parking that is not underground or
mulistorey should not be mapped with this tag. I also don't see why
this should not be mapped in case that it is possible to fully map
their physical prensence.
Why not simply:
"General entrances to a parking facility". The rest of your definition
could become an example (rather then beeing used to exclude other
usages). (I used "general entrance" here as opposed to "all
entrances", which might not be accessible to the public).
There should also be a way to distinct entraces for pedestrians and
those for cars.
What about exits from parking facilities?
2. Relation to amenity=parking
currently the wiki states:
"What about the old amenity=parking?
This new tagging scheme isn't meant to replace amenity=parking. In
areas where there is no or low res satellite images available the
current mapping scheme should still be used, also it's easier for new
mappers to use that simple tag without a relation. This proposal is
meant to be used by experienced mappers in areas where high resolution
satellite images are available and where there is a need for more
detailed information (for example car rentals services at airports).
Though is can be used for underground- and multi-storey parking (using
layers=*), it’s mainly targeted at surface parking."
I think this is not hitting the point. You still are implying that
parkings should better be mapped with this proposal in case hires
photos are available, you are still reinventing the wheel for parkings
requiring a site relation (and not specifying which tags should be
used on it).
As I see this, amenity=parking should remain the tag for the parking
(where you set the parking=surface/underground/multistorey-tag, the
fee tag, the name tag, the website-tag etc.) and your proposal should
limit itself in offering a more detailed method for single/multiple
"pure" parking spaces (plus all the other nice ideas like
parking_entrace, etc.). There is absolutely no need to change
amenity=parking or to offer alternative ways to map the same thing.
More information about the Tagging