Re: [Tagging] RFC: Door Values

[Martin Koppenhoefer]

2014-06-10 22:34 GMT+02:00 fly :

> Am 10.06.2014 21:51, schrieb Michael Maier:
> > So I created a Proposal Page for the values of the 'door' key:
> > https://wiki.openstreetmap.org/wiki/Proposed_features/door
> >
> > RFC phase is now open!
>
> I would not say that entrance=* implies door=yes. Did not find a word
> about it on the wiki page. Please, just leave them as to separate tags.
>


+1



>
> I do not think that door=no is needed but that is only a minor issue.
>


+1



>
> Myself does use barrier=door together with entrance=* though it is not
> documented either.
>


+1, although it is not completely clear when to use barrier=door and when
barrier=gate (at least not for me). There is also
barrier=full_height_turnstile etc. which might have some overlap here.

I'd also like to point out that there are already ~6000 "door"s in our db
(taginfo):
yes 
5 562
81.54%
-

hinged 
582
8.53%
-

manual 
378
5.54%
-

automatic 
87
1.28%
-

hangable 
83
1.22%
-

opening 
49
0.72%
-



if you forget about the "yes" there are quite a lot of "manual" and
"automatic".
My suggestion therefor is to be more explicit with the key identifiers, e.g.
* door_type (or door:type) for hinged / sliding / revolving / ...  (still
this is somehow ambiguous, because "type" might also be interpreted as
"glass door", "wooden door", ...)
I believe there could be also "lift_gate" (de: Hubtür) and "rolling_gate"
(de: Rolltor) as suggested values.
* door_closer = * (for mechanisms that close the door automatically, values
might be e.g. "electric", "mechanic", "no", "yes" etc.)

With respect to door_closer I'd also suggest to be more explicit with
"automatic_door" (what is automatic: opening, closing, both? And how is the
automation implemented). Not sure if an alternative key "door_opener" would
be suitable for this (but it surely would be a good complement to
door_closer).

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OpenStreetMap] #5163: paths and tracks rendering indistinguishable: your opinion?

[Pierre-Alain Dorange]

André Pirard 
wrote:

> In summary, I don't know how many of you appreciate to tag with this
> result where no tractor or motorbike driver will know which way they can
> go and where pedestrians will not know where they will quietly walk
> without meeting drivers...

Probaly they should use OpenMapQuest , Humanitary, Hike@Bike or
OpenMapSurfer for example
http://www.openstreetmap.org/#map=18/50.52902/5.81315&layers=Q
http://www.openstreetmap.org/#map=18/50.52902/5.81315&layers=H
http://hikebikemap.de/?zoom=17&lat=50.52902&lon=5.81315&layers=BTFFF
F
http://openmapsurfer.uni-hd.de/?zoom=19&lat=50.52902&lon=5.81315&layers=
B0FTFF

-- 
Pierre-Alain Dorange
OSM experiences : 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] [tl; dr] Re: cleanup broken import "fix"

[Bryce Nesbitt]

> do you have a complete list of the tags that you propose to "drop"?
> gnis:id=*   6577
> gnis:state_id=* 26
> gnis:fcode=*
> nhd:com_id=*56793
> nhd:fdate=* 56793
> Reasoning: there is no use in these tags.

There is a strong an compelling use for the GNIS id number and the NHD id
number, even though those have been imported in a number of different ways
over time. There are good reasons to retain fcode also.  Although it's not
quite as compelling, it's also harmless.

The nhd:fdate is particularly useful, as it eases manual tracking of NHD
development over time, compared to OSM development.  It also provides a bit
of history to the future manual mapper, at negligible cost in terms of
storage space or confusion.  It's useful to know a particular feature
(a) came from NHD, (b) can be looked up readily in NHD, and (3) is from a
particular era.   In questionable cases when manually editing
I will often look up the matching GNIS or NHD feature, research the
history, and then make my edit.

-
The most recent case I did this personally was a *place name out in the
middle of nowhere*.  It looked like junk and I might have just deleted it.
 Fortunately the last few human editors had preserved the gnis:id, and I
was able to look up the feature, and then link to a newspaper article about
the place.  I learned the place was a true hamlet named after the exit of a
particular railroad tunnel.  Armed with that information I was able to move
the feature to it's correct location (now a ruin), and tag it
appropriately.  Because gnis:id was preserved, the map got better and more
interesting.  Without gnis:id the detective work would have been harder and
may never have happened.

Removing the ID's removes an important thread to the history of the OSM
node, and important clues to the OSM object itself.  Putting "imported=yes"
is like painting over a mural but writing in the corner of the wall "there
was a mural here".


> In case after the cleanup the data looks too much "not-imported" could
add "imported=yes". ;)

Making imported data look "not imported" is a questionable goal.
The data *is imported*.
Pretending the data is the work of a hand mapper is a disservice to future
mappers, and disrespectful to the project that
created the data in the first place (here GNS and NHD).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bitcoin ATM (amenity=atm | currency:XBT=yes)

[Andreas Goss]

Yeah this sounds great in theory, but in reality it's not that simple.

That's probably also why there so far is no tag for money changer 
machine(!) so far (at least I did not find anything)




It's possible a device could both be an ATM as commonly understood, and a
bitcoin currency exchange device.
The tagging should keep these concepts separate, but allow them to be
combined on a single node if appropriate.


I agree with this.

Note that we do have
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbureau_de_change, which
would not be compatible with ATM, as they are both values on amenity.


__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bitcoin ATM (amenity=atm | currency:XBT=yes)

[Andreas Goss]

Am 6/10/14 12:02 , schrieb Martin Koppenhoefer:

I understand that atm can be seen as broadly as incorporating all kind
of automated telling even in the absence of actually emitting cash, but
I would prefer to use a different tag for this and use atm for machines
that actually do give you cash.


It should be considered though, that Cryptocurrency machienes might 
actually do this at some in the future.


Or Canada for example tried the MintChip 
(http://en.wikipedia.org/wiki/MintChip):
MintChip is a digital currency concept that enables digital transactions 
backed by the Government of Canada and denominated in a variety of 
currencies.


So how would you tagg an "ATM" where you put in the chip and get money 
or maybe put in the money and it gets put on the chip? (Although it does 
not look like that how it worked in that case)


__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging