Re: [Tagging] how to care about different seasonal road close?
Idea: access:conditional=no @ (winter) access:conditional=no @ (snow) note=check availability access during first trimester ... Salut i mapes yopaseopor ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to care about different seasonal road close?
On 16.03.2017 19:32, Topographe Fou wrote: > I believe we still need one user somewhere to update the data each year... I > suggest to have a scheduled bot which detect obsolete conditions value (based > on actual date) and automatically create a note on the map like "Obsolete > conditional access value, please update the feature" . +1 nice idea 0x1E6B7645.asc Description: application/pgp-keys ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to care about different seasonal road close?
I believe we still need one user somewhere to update the data each year... I suggest to have a scheduled bot which detect obsolete conditions value (based on actual date) and automatically create a note on the map like "Obsolete conditional access value, please update the feature" . Otherwise as far as I know Maps.me does not use OSRM anymore since end of 2016. They changed to another routing engine (which leads to an amazingly long list of routing issues). LeTopographeFou Message original De: hak...@posteo.de Envoyé: 16 mars 2017 3:03 PM À: tagging@openstreetmap.org Répondre à: tagging@openstreetmap.org Objet: [Tagging] how to care about different seasonal road close? The road after this point (northwards) is closed in the winter season. https://www.openstreetmap.org/note/917369#map=17/50.79221/15.32156 But like Petr says, its each year another time. I had the bad luck to route through this street with maps.me because it is not tagged for 2017, OSRM seems to not care for the year and does not route there. But graphhopper and mapzen does. And Maps.me, and because it is really a dead end when you went up there by car its a long way backwards.. So, is there a solution how to deal with roads like this, where you know that the road will be closed but you dont know the exact time? Because like here, people will forget to tag it for each year. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a way to make tags better?
What about using an existing solution, Wikibase[1] (of which Wikidata is an example)? Let's call it OSMdata. Wikibase is great because it allows for all kinds of structured data, which makes it future-proof. Some examples of use would be: We could add links to outside databases, for example Wikidata, or some other structured source that would add semantic meaning to some specialized tags. So if there is an unique ID of a special type of buoy, connect it to our seamark:type=cardinal_buoy tag on OSMdata. Create items that are tag combinations, and give those combinations additional data. For example, create an OSMdata item for amenity=place_of_worship+religion=buddhist, link it with the Wikipedia article about Buddhist temples. This gives more info about tag combinations, and in some way formalizes those combinations. Translations to all possible tag combinations (usable by all editors, and Nominatim for example) Add additional "meta tags", depending on the region they are found in. For example, default max_speed on highway=motorway in Spain. Create items for big geographical entities, like continents and oceans, and then, instead of relations, tag boundaries of those objects with the OSMdata ID. And countless other examples... [1] https://www.mediawiki.org/wiki/Wikibase Janko Mihelić ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to care about different seasonal road close?
On 16.03.2017 15:13, Daniel Hofmann wrote: >> OSRM seems to not care for the year and does not route there. > > OSRM does not route you over barriers, which there is on that way: > > https://www.openstreetmap.org/node/73331194#map=18/50.79082/15.32277&layers=D oh I forgot that I put this one there. Strange that graphhopper and mapzen route over this barrier. I deleted now the access=no because I actually dont know if the road is still closed there. Iam still waiting for Petrs answer. The tagging Iam talking about is connected to this road: https://www.openstreetmap.org/way/30899782#map=15/50.8002/15.3082&layers=D 0x2E165BB0.asc Description: application/pgp-keys 0x1E6B7645.asc Description: application/pgp-keys ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] how to care about different seasonal road close?
> OSRM seems to not care for the year and does not route there. OSRM does not route you over barriers, which there is on that way: https://www.openstreetmap.org/node/73331194#map=18/50.79082/15.32277&layers=D It has nothing to do with way tags or conditional tags from what I can see. Also check out the debug map: http://map.project-osrm.org/debug/#13.26/50.7756/15.3515 OSRM does have an experimental opening hours grammar parser for conditional tags but it's not (yet) in use by default. Cheers, Daniel J H On Thu, Mar 16, 2017 at 3:02 PM, Hakuch wrote: > The road after this point (northwards) is closed in the winter season. > > https://www.openstreetmap.org/note/917369#map=17/50.79221/15.32156 > > But like Petr says, its each year another time. I had the bad luck to > route through this street with maps.me because it is not tagged for > 2017, OSRM seems to not care for the year and does not route there. But > graphhopper and mapzen does. And Maps.me, and because it is really a > dead end when you went up there by car its a long way backwards.. > > So, is there a solution how to deal with roads like this, where you know > that the road will be closed but you dont know the exact time? Because > like here, people will forget to tag it for each year. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] how to care about different seasonal road close?
The road after this point (northwards) is closed in the winter season. https://www.openstreetmap.org/note/917369#map=17/50.79221/15.32156 But like Petr says, its each year another time. I had the bad luck to route through this street with maps.me because it is not tagged for 2017, OSRM seems to not care for the year and does not route there. But graphhopper and mapzen does. And Maps.me, and because it is really a dead end when you went up there by car its a long way backwards.. So, is there a solution how to deal with roads like this, where you know that the road will be closed but you dont know the exact time? Because like here, people will forget to tag it for each year. 0x1E6B7645.asc Description: application/pgp-keys ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a way to make tags better?
>Thoughts?
Unified tag system (iD, JOSM) + suggestions + sharing translations +
unified metadata == imho : one of key problems, but not so easy to
solve.
Some related projects :
#1. Unified Preset Management System ( Google Summer of Code/2017/Project
Ideas )
https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2017/Project_Ideas#Unified_Preset_Management_System
#2. iD Editor has a synonyms for searching for the preset (
https://github.com/openstreetmap/iD/tree/master/data/presets )
like searching any of ["elderly", "living", "nursing",
"old", "senior"] -> "Nursing Home"
"tags": {
"amenity": "social_facility",
"social_facility": "nursing_home",
"social_facility:for": "senior"
https://github.com/openstreetmap/iD/blob/master/data/presets/presets/amenity/social_facility/nursing_home.json
#3 (iD) Name Suggestion Index
https://github.com/osmlab/name-suggestion-index
and my favorite issues:
- https://github.com/osmlab/name-suggestion-index/issues/11
( Localization of name suggestion )
- https://github.com/osmlab/name-suggestion-index/issues/38 (
wikidata, McDonald's vs. Мекдоналдс, wikidata property (P1282) )
imho: the machine learning techniques to make suggestions - can be used
here ..
#4 https://github.com/geometalab/OSMTagFinder
"A search engine for OpenStreetMap tags. It uses TagInfo, translation
services (german to english), thesaurs and an adapted domain-specific
semantic net."
> There should be a way for community to suggest tag replacements.
iD Editor has deprecated.json metadata :
https://github.com/openstreetmap/iD/blob/master/data/deprecated.json
( "amenity=firepit" -> "leisure=firepit")
maybe JOSM has a similar metadata.
2017-03-16 1:57 GMT+01:00 Yuri Astrakhan :
> TLDR: Proposing several technologies to organize tags and help new users.
>
> With the rapid community growth, the same concepts tend to be described in
> more and more ways (tags/values), making the data maintenance and
> consumption increasingly difficult. taginfo site is an amazing effort to
> bring order to this space, and I would like to discuss what we can do to
> systematically improve it even further.
>
> == Suggestions ==
> In addition to presets, I think there should be an suggester service.
> JOSM, iD and other programs can use it to offer a list of suggested
> tags/values when editing, and to highlight those tags/values that appear
> significantly out of place.
> The suggested list should be the result of a complex search based on the
> position, size, type, and all other tags and their values present on the
> given object. We may even want to use machine learning techniques to make
> suggestions. I am exploring if ElasticSearch can help (disclaimer: I work
> @ Elastic).
>
> == Precise Meaning ==
> Whenever someone enters a tag=value pair, they have a very specific
> meaning in mind. If that meaning is misunderstood by other mappers or data
> consumers, that tag causes more damage than no tag - it's misleading. At
> the same time, we do not want to limit new meanings from being added to
> OSM. I think there should be a minor hinderance when adding a new tag or
> value (for enum-style tags). Whenever user tries to add a new tag, they
> should be shown a popup to provide a brief description of the new tag, and
> explain how it differs from the existing tags. The popup may also suggest
> existing tags based on the description (similar to how stackoverflow shows
> existing questions when user is typing a new one).
> This system should be enabled for tags and for "enum-like" values (tags
> like "name" clearly should not cause a popup, whereas unusual value for
> "boundary" tag should show a popup).
>
> == Cleanup suggestions ==
> There should be a way for community to suggest tag replacements. For
> example, while browsing taginfo, I saw religion=catholic and religion=
> católico, and I can suggest that it should be replaced with
> religion=christian & denomination=catholic. Afterwards, a site
> like MapRoulette could allow users to quickly check that replacements
> actually makes sense for each object, and accept or reject it.
>
> Thoughts?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Proposal for creating working group categories on wiki
Hello, I just want to let you know that I have published the following proposal https://wiki.openstreetmap.org/wiki/Talk:Wiki#Proposal_for_creating_group_ca tegories So if you interested in wiki documentation structure, I would be pleased if you could read it and comment/vote on it. Thank you. Dalibor (Chrabros) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The direction=* tag
Hi, Am 2017-03-16 um 05:13 schrieb Tod Fitch: > The “direction” tag [1] has different uses that seem disjoint to me. > To specify the orientation (compass point or degrees from north) of an object > (adit or cave entrance, etc.). > To specify direction (clockwise/counterclockwise) around a roundabout (not > sure why this is needed as it should be apparent from local laws or specified > with a “oneway=yes”). > To indicate the direction (forward/backward) a stop or yield (give way) sign > has effect along a way. > Oddly, that third use seems only for stop and yield signs but not for traffic > signals where a “traffic_signals:direction=forward | backward” tag is to be > used. However that seems to be the most used form [2]. Apparently some have > figured that if we have “traffic_signals:direction” there should be > “stop:direction” [3] and “give_way:direction” [4] tags. A direction tag is also used for railway signals, it's called railway:signal=forward/backward/both. Both tags were used the first time end of 2011 when the development of the current railway signal tagging scheme started. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The direction=* tag
Hi,The second use should not be encouraged IMHO as it is redundant with the direction of the way.Reguarding the third use, you can use either traffic_signals:direction or direction but the first form will explicitly apply to the traffic_signals while the second may apply to different tags of the node. Imagine a node which is tagged as a traffic light (or a stop) and a crossing or a camera. To which one the direction apply if you don't specify it? If the second form is used, then it applies to all tags which may be associated to a direction. This is how I understand and use it.From my understanding stops, give ways and traffic lights can be mapped the same way but editors (JOSM, iD) have implemented presets for those features at different point in time without feeling the need for consistency. I know that iD is currently doing the job of having a consistent behavior for those three features and that they might prefer (traffic_signals|stop|give_way):direction instead of direction (to be confirmed). They are also working to display the direction on the node on the map.LeTopographeFouDe: t...@fitchdesign.comEnvoyé: 16 mars 2017 5:15 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: [Tagging] The direction=* tag The “direction” tag [1] has different uses that seem disjoint to me.To specify the orientation (compass point or degrees from north) of an object (adit or cave entrance, etc.). To specify direction (clockwise/counterclockwise) around a roundabout (not sure why this is needed as it should be apparent from local laws or specified with a “_oneway_=yes”).To indicate the direction (forward/backward) a stop or yield (give way) sign has effect along a way.Oddly, that third use seems only for stop and yield signs but not for traffic signals where a “traffic_signals:direction=forward | backward” tag is to be used. However that seems to be the most used form [2]. Apparently some have figured that if we have “traffic_signals:direction” there should be “stop:direction” [3] and “give_way:direction” [4] tags.And other things where a direction like tag might be used, like roof aspect have their own tags (“roof:direction=*”) [5] which follow the syntax and semantics of the first definition of the “direction=*” tag.It seems to me that the first and the third definitions should be split into separate tags with the second definition deprecated.From a data consumer point of view, there may not be a conflict as map rendering is likely to only use the bearing definition while routing would use the forward/backward definition. Though I suppose that a really detailed map may wish to show the actual angle of a stop or yield sign as they are not necessarily exactly aligned with the traveled way. From a mapper’s point of view having totally different meanings for a tag based on context seems confusing.Since the “forward” and “backward” values are most used, it may be reasonable to keep the third definition of that tag even though it is inconsistent with “traffic_signals:direction”.Should we come up with a new tag to replace the angle/aspect meaning of the “direction=*” tag? If so, what tag name would make sense.“Bearing” (some uses which seem to follow the first definition of “direction”) [6]“Aspect” a couple of instances in use but not clear to me what was intended. [7][8]Thoughts?[1] https://wiki.openstreetmap.org/wiki/Key:direction[2] https://taginfo.openstreetmap.org/keys/direction#values[3] https://taginfo.openstreetmap.org/keys/stop%3Adirection[4] https://taginfo.openstreetmap.org/keys/give_way%3Adirection[5] https://wiki.openstreetmap.org/wiki/Key:roof:direction[6] https://taginfo.openstreetmap.org/keys/bearing#values[7] https://taginfo.openstreetmap.org/keys/Aspect#values[8] https://taginfo.openstreetmap.org/keys/aspect#values___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The direction=* tag
Am 16.03.2017 05:13, schrieb Tod Fitch: It seems to me that the first and the third definitions should be split into separate tags with the second definition deprecated. I agree that this situation is suboptimal. The second meaning has nothing to do with a direction but with a sense of rotation. So, I agree it should be dropped first, if any. Since the “forward” and “backward” values are most used, it may be reasonable to keep the third definition of that tag even though it is inconsistent with “traffic_signals:direction”. I don't agree. The uses of direction for forward/backward are in the same magnitude of order as for compass directions. A factor of 2 is not relevant. Both uses have their tradition and they are not likely to be mixed. The compass thing has more of an absolute direction than the forward/backward one, as it only specifies a binary feature relative to another oriented feature. Best regards, Carsten ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a way to make tags better?
Hi,
there have been many plans/concepts in the past that tried to solve
the same problems. I have lost track of the different endeavours and
what they wanted to achieve and why they didn't. I remember a talk by
David Earl about something tagging-related at a SOTM conference years
ago; I remember some work being done by Stefan Keller at Rapperswil, and
also quite recently someone did a little "big data" stuff with tags and
tried to automatically find out "if you tag this you might also want to
use these tags" rules or so. You should definitely also google for
"Harry Wood Community Smoothness" and view that 2009 talk of his.
On 16.03.2017 01:57, Yuri Astrakhan wrote:
> == Suggestions ==
> In addition to presets, I think there should be an suggester service.
> JOSM, iD and other programs can use it
Precursors of such a suggester service are probably the presets offered
by all big editors, and in the case of JOSM also the validator.
Currently there's not even a database of presets or validation rules
shared by all editors. Maybe that could be a first step (having a
"preset service" and a "validation service", but it would need to
provide some kind of offline capability too for editors that can't rely
working internet connection while being used).
Great power lies in creating and maintaining these services because you
can essentially control what tags are used "in the wild". If the
introduction of new tags is made more complicated, the power of the
maintainers will be even greater. This is something that we, as a
community, should think about - whom do we want to have this power?
> We may even want to use machine learning techniques to
> make suggestions.
I am critical of that because it would remove the community's ability to
check the algorithms. Currently I can look at the code of an editor and
discern in which situations it will offer which choices to the user, and
modify that if necessary. Once machine learning is employed, this will
be more difficult, and editors could start suggesting stuff that we
don't even want them to.
> == Precise Meaning ==
> Whenever someone enters a tag=value pair, they have a very specific
> meaning in mind. If that meaning is misunderstood by other mappers or
> data consumers, that tag causes more damage than no tag
I'm not sure that (a) this is true and (b) the mapper must make more of
an effort to be understood - maybe it is the consumer who must make more
of an effort to understand?
> they should be shown a popup
There's a long-going and mostly humorous feud between JOSM-leaning
people ("let's show a popup") and ID-leaning people ("gah! popups ruin
the UX").
> == Cleanup suggestions ==
> There should be a way for community to suggest tag replacements. For
> example, while browsing taginfo, I saw religion=catholic and religion=
> católico, and I can suggest that it should be replaced with
> religion=christian & denomination=catholic. Afterwards, a site
> like MapRoulette could allow users to quickly check that replacements
> actually makes sense for each object, and accept or reject it.
This is a very contentious topic even if you leave religion out of it.
There's a ton of things that can go wrong. In your example, one would
have to ensure that only people who understand religion in the
particular country will participate in the verification (plus there will
be "helpful" people trying to automate the process). At DWG we have to
deal with such well-meaning but erroneous mass edits all the time. For
example (that was years ago), someone in Germany tried to change all
"denomination=evangelical" to "denomination=protestant" in Germany
because - that was his reasoning - the German term for "protestant" is
"evangelisch" leading to many mappers mis-mapping a protestant church as
"evangelical". But of course some of them were "evangelical" on purpose.
Even today, some people are very eager to "deprecate" old tags in favour
of something new they think should be used instead. Giving them a
streamlined process to get rid of "old" tags sounds like inviting trouble.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
