Re: [Tagging] Facts and opinions

2019-01-09 Thread Bryan Housel

> On Jan 9, 2019, at 8:23 PM, Stefan Keller  wrote:
> 
> Hi,
> 
> As one of the originators of this thread I'd like to second that the
> Wiki is important. It's not only a documentation tool but also a
> communication. We all need patience with Wikis and it's curation and
> users - like we e.g. have patience with when we're discussing things
> about iD presets or iD functionality (like Copy which remained
> unimplemented since 2013 - hint to Bryan :-))

Stopped reading here and Unsubscribing. 
You are not funny, and I don’t need the stress that this mailing list brings. 

Good luck with tagging & Bye 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Facts and opinions

2019-01-09 Thread Bryan Housel


> On Jan 9, 2019, at 1:39 PM, Mateusz Konieczny  wrote:
> Jan 9, 2019, 7:33 PM by bhou...@gmail.com:
> On Jan 9, 2019, at 1:18 PM, Mateusz Konieczny  > wrote:
> Jan 7, 2019, 4:12 PM by bhou...@gmail.com :
> And on “the wiki”, I have basically given up on the OSM wiki because it 
> contains so much wrong information and opinion, and I’m tired of having my 
> edits reverted. I just recently had another issue where we added a traffic 
> signal tag that was already used, and then someone edited the wiki to rant 
> about how iD is wrong and for people to not use the tag
> What is your username on wiki?
> 
> I expected it to be Bhousel but this description seems to not match 
> https://wiki.openstreetmap.org/w/index.php?title=Special:Contributions==500=user=Bhousel=0===
>  
> 
> Yes that is - pretty obviously - me. What it is that you are feigning 
> confusion about?
> For start, I see no edits related to traffic signals.


Yes, I did not edit the page.  (because I don’t care anymore)

Some people were upset that iD defaults normal traffic signals to have the tag 
`traffic_signals=signal`.  Here is an issue:
https://github.com/openstreetmap/iD/issues/5016 


M!dgard was mad that I closed the issue and so he started editing the wiki to 
say that iD is wrong
https://wiki.openstreetmap.org/w/index.php?title=Key:traffic_signals=1605351
 


Minh and another editor have tried to tone down his language.  He keeps putting 
it back.

This is one of the reason why I stopped caring about the wiki..

It’s not documentation.  It’s just a bunch of prescriptive advice by random 
people.  Most of the people involved don’t even work on software.  They’re just 
really into tagging and arguing, and I don’t have time for it.



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


Re: [Tagging] Facts and opinions

2019-01-09 Thread Bryan Housel
> On Jan 9, 2019, at 1:18 PM, Mateusz Konieczny  wrote:
> Jan 7, 2019, 4:12 PM by bhou...@gmail.com:
> And on “the wiki”, I have basically given up on the OSM wiki because it 
> contains so much wrong information and opinion, and I’m tired of having my 
> edits reverted. I just recently had another issue where we added a traffic 
> signal tag that was already used, and then someone edited the wiki to rant 
> about how iD is wrong and for people to not use the tag
> What is your username on wiki?
> 
> I expected it to be Bhousel but this description seems to not match 
> https://wiki.openstreetmap.org/w/index.php?title=Special:Contributions==500=user=Bhousel=0===
>  
> 
> 


Yes that is - pretty obviously - me.  
What it is that you are feigning confusion about?

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


Re: [Tagging] service

2019-01-08 Thread Bryan Housel
> On Jan 8, 2019, at 2:30 AM, Simon Poole  wrote:
> 
> Am 07.01.2019 um 16:12 schrieb Bryan Housel:
>> ...
>> On “both is OK”. the `service:vehicle` issue was because we can’t use the 
>> same key `service=*` to contain both things like `tyres` (a few thousands) 
>> and `driveway` (a few millions).  Sorry, but the `service=tyres` has to go.  
>> A few thousand uses is not “established tagging practice”.  And I doubt that 
>> that usage was ever discussed here or proposed either.  If it was, I missed 
>> the proposal where someone said “lets put tyres in a tag already used 3 
>> million times for something else”.  My “no” vote on such a thing would not 
>> have mattered anyway.
>> 
>> ...
> 
> This is not a given, your problem exists just as a consequence of iD
> retrieving tag values from taginfo and how iD presets are designed.
> Everything else (as in any other editor) definitely doesn't have an
> issue with sub-tag keys using the same name as there is more than enough
> context to be able to differentiate the different usages. 

How does Vespucci work around this?
Do you:
- just build in lists of what all the acceptable values are that people are 
allowed to enter in different contexts?
- or let people type anything but expect them to already know what the good 
values are from wiki research?
- or just don’t support the `service=` key in some contexts?
- or something else?

(skipping the rest of the email about `sells=`.. it’s way off topic)

Thanks, Bryan


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


Re: [Tagging] service

2019-01-07 Thread Bryan Housel
> On Jan 7, 2019, at 6:22 PM, Graeme Fitzpatrick  wrote:
> Hi Bryan
> I've just created a new page for shop=caravan 
> https://wiki.openstreetmap.org/wiki/Shop%3Dcaravan 
> , which i copied from the 
> shop=car page.
> 
> As such, it's also copied across the various service=* tags dealer /  parts / 
> repair etc
> Does this create a problem? :-(
> More than happy to change it if it does, but what is the best / preferred 
> format?


Yes, strong preference for `service:vehicle:*=yes/no` instead of `service=*`
details here:
https://github.com/openstreetmap/iD/issues/4497 

https://github.com/openstreetmap/iD/issues/3535 


Thanks, Bryan___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Facts and opinions

2019-01-07 Thread Bryan Housel
> On Jan 7, 2019, at 6:01 PM, Joseph Eisenberg  
> wrote:
> 
> Doesn’t taginfo use the wiki as the source of tags that are listed?


No, taginfo’s source is the actual tag data from the OSM database.




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


[Tagging] Changeset tag for issue closing

2019-01-07 Thread Bryan Housel
iD now integrates with the KeepRight Q/A tool.. This is pretty great, and you 
should try it out:
https://twitter.com/bhousel/status/1081398222176817152 



But I have a tagging question.  

As we roll out this feature, as well as other Q/A tool integrations, some 
people would like to be able to have the issues that they are closing appear in 
their changeset comment, or hashtag, or some other tag.

It seems like the obvious solution - adding a changeset comment like “closes 
#keepright-123” - is ok but not great.  It doesn’t really say what the user 
did, and we will quickly run into the 255 char limit if the user closes a lot 
of issues.

So I’m thinking of introducing changeset tags like “closes:x=123;456;789” 
where x can be a tracking service like “keepright”, “osmose”, “improveosm”, 
“maproulette” or any other issue tracker we want to connect iD to.  

Thoughts?  

Reply here or on  https://github.com/openstreetmap/iD/issues/5679 


If there aren’t any serious objections, I’ll probably add this in a few days.

Thanks!
Bryan

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


Re: [Tagging] Facts and opinions

2019-01-07 Thread Bryan Housel
> Just recently the iD Editor maintainer added more multiCombo functions
> (like [3]) and presets key (like "service:vehicle" [4]). Both is OK
> per se, but the latter preset was undocumented on the Wiki, and
> obviously the iD Editor maintainer prefers namespaces over semicolons
> for handling multiple values - and both issues seem to be completely
> undiscussed!


Amazingly you squeezed 4 wrong things into two sentences.  Just to set the 
record straight:

On my “preference”, both namespaces and semicolons are fine, I don’t have a 
preference and iD handles both. 

On “both is OK”. the `service:vehicle` issue was because we can’t use the same 
key `service=*` to contain both things like `tyres` (a few thousands) and 
`driveway` (a few millions).  Sorry, but the `service=tyres` has to go.  A few 
thousand uses is not “established tagging practice”.  And I doubt that that 
usage was ever discussed here or proposed either.  If it was, I missed the 
proposal where someone said “lets put tyres in a tag already used 3 million 
times for something else”.  My “no” vote on such a thing would not have 
mattered anyway.

On “completely undiscussed”, we already discuss tagging extensively in public 
on the iD GitHub - because this is where issues with bad tags tend to manifest 
themselves.  The osm-carto project sees their share too.  I believe more people 
follow the GitHub projects than are subscribed to this tagging mailing list.  
I’ve also posted plenty of information on this mailing list but it seems that 
people don’t read it.  This is at least the third time we’re discussing this 
exact issue on this mailing list.

And on “the wiki”, I have basically given up on the OSM wiki because it 
contains so much wrong information and opinion, and I’m tired of having my 
edits reverted.  I just recently had another issue where we added a traffic 
signal tag that was already used, and then someone edited the wiki to rant 
about how iD is wrong and for people to not use the tag.  Where before, I 
thought the wiki was “not perfect”, now I’m of the opinion that it’s actively 
harming OpenStreetMap.  I encourage everyone to just disregard everything 
that’s on the wiki and go by what taginfo says as far as how the tags are used 
and what the accepted values are.  If something is “not documented on the wiki” 
that means nothing because the wiki is not documentation.

Anyway hope that clears up some of the confusion. If not - I’m sure we’ll 
discuss these exact same issue again here in another 9 months anyway.

Thanks, Bryan


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


Re: [Tagging] A fool with a tool ... Vehicle service tags

2019-01-02 Thread Bryan Housel
We discussed it here on this list last year.  You started the thread even, so 
you can’t pretend like you "just realized” it.   
I even asked people to update the wiki.
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036095.html 

 
Anyway, be nice & happy new year.



> On Jan 2, 2019, at 11:13 PM, Thilo Haug OSM  wrote:
> 
> Hi all,
> 
> just realized there's a "great" new feature in ID editor,
> lots of senseless service tags in this format :
> https://taginfo.openstreetmap.org/search?q=service%3Avehicle%3A
> 
> Seems to be over a year ago that someone decided to avoid conflicts
> between the "street" and the "car" services :
> https://wiki.openstreetmap.org/wiki/Key:service:vehicle
> 
> They just forgot to check whether it had some influences on existing
> tagging schemes
> and didn't even adjust the "shop=car" wiki page (whose tagging scheme
> apparently lead to this decision).
> 
> This leads to entries like this one :
> https://www.openstreetmap.org/way/44809
> 
> Thoughts ?
> Ideas how to fix that ?
> At least this opulent tagging scheme should be deactivated ASAP in ID.
> 
> Cheers,
> Thilo
> 
> 
> ___
> 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] iD news - 2.12.0 released 

2018-12-28 Thread Bryan Housel
> On Dec 27, 2018, at 7:51 PM, Graeme Fitzpatrick  wrote:
> Thanks Bryan
> Separate request for each brand, or one for multiples?

either is fine!


> & what do you need - just name & what they do / type of store & speciality?

Mainly just the name and whatever tags should go with it (`shop=whatever`).


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


Re: [Tagging] iD news - 2.12.0 released 

2018-12-27 Thread Bryan Housel
Glad you like it!   The brand name list is tracked in this repository:
https://github.com/osmlab/name-suggestion-index

So just open an issue or pull request there if you know of anything to be added!
Thanks, Bryan



> On Dec 27, 2018, at 6:07 PM, Graeme Fitzpatrick  wrote:
> 
> 
> 
> On Mon, 10 Dec 2018 at 12:14, Bryan Housel  <mailto:bhou...@gmail.com>> wrote:
> 
>   Brand Name Suggestions
> We've released a huge upgrade to the brand name suggestions in iD. Thank you 
> to everyone who volunteered to match brand names to their proper 
> OpenStreetMap tags.  Follow the brand name suggestion project here:  
> https://github.com/osmlab/name-suggestion-index 
> <https://github.com/osmlab/name-suggestion-index>
> Try adding some branded businesses to the map - `brand`, `brand:wikidata`, 
> and other tags will be set for you.
> 
> Have used this a couple of times now & very handy!
> 
> Is there a procedure for suggesting more brand names to include?
> 
> Thanks
> 
> Graeme
> ___
> 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] iD news - 2.12.0 released 

2018-12-09 Thread Bryan Housel
Last week, after several months of work, we released iD v2.12.0 for editing 
OpenStreetMap.
I hope you like it!  Here are some of the highlights from the release:

✌️  2-finger pan and zoom gestures
Mac users can now use 2 finger trackpad gestures to pan and zoom the map.
Try swiping with 2 fingers to pan, or pinching out/in to zoom and unzoom. 
You'll be less likely to accidentally drag nodes!

  Directional way markers
iD now draws triangular markers on the "down" side of ways where the direction 
matters. Thanks, Huon Wilson for this feature!
Ways with a direction include cliffs, coastlines, retaining walls, kerbs, guard 
rails, embankments.

↔️  Resizable sidebar
You can now resize the sidebar, or hide it completely. Shout out to Quincy 
Morgan for his work on this!
Try dragging the sidebar to resize it, or click the hide button in the top 
toolbar. The top bar buttons can also shrink on narrower screens.

  Brand Name Suggestions
We've released a huge upgrade to the brand name suggestions in iD. Thank you to 
everyone who volunteered to match brand names to their proper OpenStreetMap 
tags.  Follow the brand name suggestion project here:  
https://github.com/osmlab/name-suggestion-index 

Try adding some branded businesses to the map - `brand`, `brand:wikidata`, and 
other tags will be set for you.

  More Wikidata integration 
iD now displays linked data if a feature has a wikidata tag, and will protect 
fields like name and brand from direct editing.
Make sure prominent features have a Wikidata tag, for added protection against 
accidental changes.

  More features for working with relations
Hovering over a relation or member in the sidebar will highlight it on the map. 
You can also download incomplete sections, and zoom to inspect relation 
children. Thanks, Quincy Morgan!
Check out the "All Relations" and "All Members" sections of the sidebar to try 
out the new relation editing tools.

‍  Hacktoberfest happened! 
We merged 40 pull requests during the month of October. Thank you to all of our 
new contributors!


As always, the update includes many other usability improvements and new 
presets - check out the changelog for all the details.
(It’s pretty epic, thanks to the dozens of people who worked on this release!)

Changelog: 
v2.12.0 changelog:  
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#2120 


Twitter:
v2.12.0 announcement:  https://twitter.com/bhousel/status/1070068684297768960 
  
Quincy shows off the new features:  
https://twitter.com/quincylvania/status/1070176229620244481 


Reddit:
Thread:  
https://www.reddit.com/r/openstreetmap/comments/a39y2b/the_new_features_of_id_2120_in_one_twitter_thread/
 



Follow and star the iD project on GitHub to show your support:  
https://github.com/openstreetmap/iD 
And follow me on Twitter https://twitter.com/bhousel 
 for the latest iD news. 

Thank you!
❤️ Bryan, and the rest of the  team.

P.S.
We are getting together in NYC to hack on iD during the week of Dec 17-21 at 
the Facebook office.  Space is limited, so please private message me if you 
want to attend!  We also have started a bi-weekly sync for the core development 
team.  If you want to work on iD, we’d love your help!

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


Re: [Tagging] unmarked crossing, tactile paving, lowered kerbs / was: 2 meaning for crossing=zebra

2018-10-26 Thread Bryan Housel
> So how would you tag this situation:  
> https://www.google.com/maps/@-28.0707782,153.4362109,3a,75y,140.17h,73.2t/data=!3m7!1e1!3m5!1s0bHjLjjqqe1rrdNWfLu94g!2e0!6s%2F%2Fgeo1.ggpht.com%2Fcbk%3Fpanoid%3D0bHjLjjqqe1rrdNWfLu94g%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D296.4197%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656
>  
> 
> 
> There is a footpath along the side of the road, which drops to road level via 
> a lowered kerb, to meet up with another lowered kerb on the other side of the 
> road. There are no signs or markings of any sort.
> 
> I map them as crossing=unmarked

You got it - good example of a `crossing=unmarked`.  
These are very common in the US suburbs.

Thanks, Bryan


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


Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Bryan Housel
> On Oct 26, 2018, at 6:44 AM, Tom Pfeifer  wrote:
> 
> Tagging "unmarked crossings" does not make sense for me. An unmarked crossing 
> is defined in OSM by a road and a footway sharing a node, there is no need 
> for a tag here, as there is nothing special.
> 
> Otherwise I would need to set a node every meter on the road, tagging it 
> "unmarked crossing" because I can cross the road everywhere.

How fortunate for you! 
Try to imagine what crossing the street might be like for someone who can not 
cross the road everywhere and could benefit from guidance to tell them where it 
is possible or safe.


> And I hate it when the satnav announces a warning for the upcoming crossing, 
> and there comes nothing the requires extra attention.

Again, try to have some empathy towards other users who are not you.  It’s 
great that you are such an attentive driver.  If the satnav warning helps bad 
drivers not hit kids, I’m all for it.


Thanks, Bryan



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


Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Bryan Housel
> On Oct 26, 2018, at 6:26 AM, marc marc  wrote:
> 
> Le 26. 10. 18 à 01:18, Bryan Housel a écrit :
>> I don’t like `crossing=zebra` either.<...> iD will support these 2 presets:
>> - `crossing=marked` which is labeled “Marked Crosswalk"
>> - `crossing=unmarked` which is labeled “Unmarked Crossing”
> 
> thanks for understanding that a issue exist, the first step
> to solve it :)
> 
> but I don't understand how the new preset will solve the problem


Well.. The “problem” is not a tag problem, but rather a people problem.  

Even experienced OSM contributors can’t agree on what the top values for 
crossing mean (this thread should make this point clear) and beginner 
contributors are hopelessly lost because the current top values don’t even 
sound like what they are trying to represent.  (you can review the top values 
here:  https://taginfo.openstreetmap.org/keys/crossing#values)

“crossing=uncontrolled” - all new people I’ve talked to think this means “no 
markings”.  People with experience in traffic planning understand road markings 
as control devices.

“crossing=traffic_signals” - new people usually assume this means “has a button 
and walk/don't walk sign” - It says nothing about the markings or the safety of 
whether you should even cross there.  In many places there are traffic_signals 
but no markings.

“crossing=zebra” - new people think this is weird, but understand it means 
stripes on the ground like the Abbey Road album cover. 

“crossing=island” - nobody I have talked to knows how to use this tag.




> since you put the marking information in the key whose main use is to 
> inform the security of the passage (presence or not of traffic lights)
> We had 2 incompatible schemas, let's avoid to create a third one :)

`crossing=marked` and `crossing=unmarked` are not new.  They’ve been in use for 
years.

They solve the problem in that they are unambiguous and beginner-friendly.

Thanks,
Bryan



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


Re: [Tagging] 2 meaning for crossing=zebra

2018-10-25 Thread Bryan Housel
Oh!  I don’t like `crossing=zebra` either.  Not sure whether you caught the end 
of that issue #4788, but anyway I've decided I'm tired of hearing people 
complain about `crossing=zebra` so going forward iD will support these 2 
presets: 

- `crossing=marked` which is labeled “Marked Crosswalk"  
- `crossing=unmarked` which is labeled “Unmarked Crossing” 

`crossing=zebra` is still supported as a legacy, unsearchable preset, so things 
will still look the same.

(these changes will go live with the next version of iD, whenever that will be 
released)

thanks!
Bryan




> On Oct 25, 2018, at 5:39 PM, marc marc  wrote:
> 
> Hello,
> 
> I have a big issue with crossing=zebra.
> it prevent to fill in the other value for crossing like 
> crossing=traffic_signals crossing=uncontrolled
> the wiki [1] said that crossing=zebra is a shortchut for 
> crossing=uncontrolled + crossing_ref=zebra in the UK
> but a lot of zebra also in UK and outside UK have traffic_signals
> and must be tagged with crossing=traffic_signals
> so at the end, crossing=zebra has no meaning... maybe the previous 
> contributor mean crossing=uncontrolled + crossing_ref=zebra
> but maybe he mean only crossing_ref=zebra
> I fix a few week a lot of crossing=zebra crossing_1=traffic_signals
> or crossing=zebra;traffic_signals that show it's an issue.
> 
> a issue was closed in iD [2] some time ago because "the dev dislike 
> crossing_ref" (it is in fact a very ugly name for the tag)
> right now josm [3] is changing preset to drop cossing_ref=zebra
> in favor of crossing=zebra
> 
> I am part of a group of a group of mappers working on accessibility
> are planning to open a talk to fix it but the news of the commit flow 
> preceded us
> 
> so my request is : how to avoid again a multi-meaning tag ?
> 
> may/must we separate the type of crossing from the ground marking ?
> in short : move away crossing=zebra in another tag ? if yes
> is crossing_Re so ugly than in the same time another tag need
> to be used for the ground marking ?
> 
> let's avoid the argument of "there are too many cases to fix",
> it doesn't scare me to propose a mass edition once a coherent scheme
> has been found. but having half tools that fill a value with another 
> meaning than other or historical meaning is a big issue for the use
> of the data.
> 
> [1] https://wiki.openstreetmap.org/wiki/Key:crossing
> [2] https://github.com/openstreetmap/iD/issues/4788
> [3] https://josm.openstreetmap.de/ticket/16793
> 
> Regards,
> Marc
> ___
> 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] amenity=clinic or healthcare=clinic

2018-10-17 Thread Bryan Housel
Yes, iD now adds the `healthcare=` tags alongside the legacy tags.
https://github.com/openstreetmap/iD/issues/3589

We also considered asking users if they want to “upgrade” old tags, but I 
received enough pushback that I just decided to drop the idea.
https://github.com/openstreetmap/iD/issues/4591
(I still think it’s worth revisiting someday)

Thanks, Bryan




> On Oct 17, 2018, at 2:45 PM, Clifford Snow  wrote:
> 
> When reviewing a new users first edits, I noticed they use bot amenity=clinic 
> and healthcare=clinic. I was surprised to see both are document on the wiki - 
> amenity=clinic [1] and healthcare=clinic [2] 
> 
> They seem redundant. Should both exist or should amenity=clinic be 
> deprecated? (I like the healthcare=clinic better mainly because amenity is so 
> overused.)
> 
> The edits were done with iD which would indicate they have both tags. 
> 
> [1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dclinic 
> 
> [2] https://wiki.openstreetmap.org/wiki/Key:healthcare 
> 
> 
> -- 
> @osm_seattle
> osm_seattle.snowandsnow.us 
> OpenStreetMap: Maps with a human touch
> ___
> 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] Traffic sign direction tagging..

2018-10-01 Thread Bryan Housel
> On Oct 1, 2018, at 5:23 PM, yo paseopor  wrote:
> 
>  > ^ This is the problem.  The wiki says we are supposed to do something like 
> `traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to 
> be based on a "toplevel" tag like `traffic_sign=*` not 
> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark? many 
> of their tags have this issue too, where they put a value in the key part, 
> and so we can’t turn it into a preset).
>  
>  JOSM can do this change (when you change a way) as you can see on 
> https://i.imgur.com/NnLpKWR.jpg 

iD will also do this change when reversing a way.  That’s not what my email is 
about.


>  If you read taginfo you can find for forward subtags 
> https://taginfo.openstreetmap.org/search?q=%3Aforward 
>  more than 80 
> nodes. If you read taginfo for backward 
> https://taginfo.openstreetmap.org/search?q=%3Abackward 
>  you can find more 
> than 80 nodes. Are you saying iD doesn't recognise all these tags with 
> forward and backward subtags?

Nope, not saying that at all.


>  I give you a solution: make two presets: one for traffic_sign:backward and 
> other with the same values for traffic_sign:forward. 

That’s a bad solution, so instead we’re going to solve the problem of 
indicating traffic sign direction the same way it’s already solved for traffic 
signals.  `traffic_sign:direction=forward/backward` - simple.  I will even 
convert all the existing traffic signs tagged with `traffic_sign:forward` or 
`traffic_sign:backward` to work this way if you want.  It’s an unambiguous tag 
change.

I wouldn't know how to explain to mappers when to use a “Traffic Sign” vs a 
“Forward Facing Traffic Sign” vs a “Backward Facing Traffic Sign” much less 
translating these concepts to dozens of different languages.


Thanks, Bryan

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


Re: [Tagging] My "weirdly unnatural aversion to relations"

2018-09-29 Thread Bryan Housel
> On Sep 29, 2018, at 6:56 PM, Paul Johnson  wrote:
> 
> I honestly don't understand why, ten years since it's introduction as OSM's 
> third basic primitive, there's still this weirdly unnatural aversion to 
> relations, even though they're quite a powerful primitive in our toolbox.

From my own perspective as the main developer on the main editor for OSM, the 
reason I don’t like relations very much is because:
- every type of node basically works the same.
- every type of linear way basically works the same.
- every type of polygonal area basically works the same 
- every type of relation is an edge case that requires special code in order 
not to break.  

Relations are also problematic because they are unbounded.  Want to make a 
boundary relation with a million child ways?  This is allowed.  Want to ensure 
that all those ways are connected?  It may take minutes to download them all.  

They’re almost even a security threat.  I’m willing to bet a black hat could 
design and upload a relation that would destroy OSM.. Or at least, crash every 
piece of software in the stack that we rely on:  mapnik, osmium, and any editor 
that tries to touch it.  

Anyway, I’m not totally against them, but every one of them is different and I 
can't spend weeks or months supporting every kind of relation or public 
transport schema people dream up unless it’s super critical for building a 
useful map (like turn restrictions).  They are really best for features that 
can not be mapped any other way.

Thanks, Bryan

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


[Tagging] Traffic sign direction tagging..

2018-09-27 Thread Bryan Housel
Hey Tagging List!

While reviewing a pull request to add Traffic Sign presets to iD, I came across 
a tagging issue with how traffic sign directions are tagged.
The details are here https://github.com/openstreetmap/iD/pull/5333 
 and relevant guidance on the 
OSM wiki is quoted below:   

> Traffic sign as a separate node
> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_a_separate_node 
> 
> Create a separate node beside the road at the position of the actual sign... 
> You can use the `direction=*` tag to describe the facing orientation of the 
> sign by using an angle or cardinal direction.

^ This is ok!  iD supports `direction=*` and will even render a view cone at 
higher zooms so mappers can see which direction it points.

> Traffic sign along a way
> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_part_of_a_way 
> 
> Create a new node within the relevant way next to the sign... You can use 
> `traffic_sign:forward=*` to specify that this sign affects vehicles moving in 
> the same direction as the OSM way. The opposite direction can be tagged with 
> `traffic_sign:backward=*`. Formerly the `direction=*` key has also been used 
> to describe the affected direction. But its common meaning has changed to 
> Relative to Geographic North.

^ This is the problem.  The wiki says we are supposed to do something like 
`traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to be 
based on a "toplevel" tag like `traffic_sign=*` not `traffic_sign:forward=*` or 
`traffic_sign:backward=*` (remember seamark? many of their tags have this issue 
too, where they put a value in the key part, and so we can’t turn it into a 
preset).

So instead what we’ve decided to do is:  Support a tag `traffic_sign:direction` 
which works exactly the same as the existing and well supported 
`traffic_signals:direction`

See https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction 

iD already has support for  `traffic_signals:direction=forward/backward`

To keep things simple, we'll do the same thing for traffic signs:
`traffic_sign:direction=forward/backward`

Thanks,
Bryan

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


Re: [Tagging] tagging a gamesroom?

2018-08-17 Thread Bryan Housel
Probably `leisure=amusement_arcade`, which is not great but the best tag we 
have.
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Damusement_arcade 


Thanks, Bryan



> On Aug 17, 2018, at 9:29 AM, Philip Barnes  wrote:
> 
> On Fri, 2018-08-17 at 13:04 +0100, seirra wrote:
>> what should a games room (think things like darts, pool/snooker,
>> card 
>> games) be tagged as? when i looked around i couldn't seem to find
>> any 
>> official consensus or unofficial for that matter
>> 
> 
> I would say they are not normally standalone objects but part of
> something else. For example I expect most pubs to have a dartboard,
> dominoes and you can play cards anywhere you have a table. Some will
> also have a pool table, but they have mostly gone out of fashion.
> 
> Standalone pool and snooker clubs certainly exist, would probably add
> some sort of sub tag to a social club.
> 
> Phil (trigpoint)
> 
> ___
> 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] Car pound, tow pound etc.

2018-08-17 Thread Bryan Housel
I’d strongly prefer not to use `landuse` for this.  These facilities are 
sometimes indoor garages.  
(Anytime we use `landuse` for something that might also be mapped a building or 
POI, we’re doing it wrong.)

`amenity=impound` makes sense to me.

Here is some more information about the process:
https://en.wikipedia.org/wiki/Vehicle_impoundment

Thanks, Bryan



> On Aug 17, 2018, at 9:14 AM, Paul Allen  wrote:
> 
> On Fri, Aug 17, 2018 at 12:53 PM, Jean-Marc Liotier  > wrote:
> When the police impounds a wrongly parked vehicle, it takes it to a
> managed parking facility where they keep it until the infraction is
> resolved. How should we tag that place ?
> 
> How about landuse=depot?
> 
> -- 
> Paul
> 
> ___
> 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] iD news - v2.10.0 with OSM Notes and more

2018-08-03 Thread Bryan Housel
We released iD v2.10.0 last week!  


  OSM Notes  
You can now create, comment on, and resolve OpenStreetMap notes from within iD! 
 This work was done as part of Thomas Hervey's 2018 Google Summer of Code 
project, and you can read about it in his diary here:  
https://www.openstreetmap.org/user/Thomas_Hervey/diary/ 

Thanks Thomas Hervey and mentor Marc Farra!
Activate the OpenStreetMap notes layer by opening the Map Data pane (shortcut F)
Let’s close all the notes! 


  Detach Node
We've added a new Detach Node operation to remove a tagged node from a way. 
Thanks @Psigio!
With a node selected, use the right-click edit menu to find the Detach command 
(shortcut E)


↗️  Resizable Photo Viewer
The photo viewer (Mapillary, OpenStreetCam, and Bing Streetside) is now 
resizable by dragging any of its edges.  Thanks Matias Volpe!
Try activating one of the streetlevel photo layers (shortcut F) and resizing 
the viewer.


As always, the update includes several other usability improvements and new 
presets - check out the changelog for all the details.

Changelog: 
v2.10.0 Changelog:  
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#2100 


Twitter:
v2.10.0 announcement:  https://twitter.com/bhousel/status/1022527242193252356 

OSM Notes: https://twitter.com/bhousel/status/1019021979117072386 

Detach Node:  https://twitter.com/bhousel/status/1021448718111985664 


State of the Map!!
I gave a lightning talk about iD at last week’s State of the Map conference in 
Milan!  ⚡️
So many features have shipped in the past year, I had to really race to get 
through it all.
You can watch it here:  
https://www.youtube.com/watch?v=Jn5VWd7C6_g=youtu.be=2989 

Or share this Tweet:  https://twitter.com/bhousel/status/1023707520525901824 



Follow and star the iD project on GitHub to show your support:  
https://github.com/openstreetmap/iD 
And follow me on Twitter https://twitter.com/bhousel 
 for the latest iD news. 

Thank you!
❤️ Bryan, and the rest of the  team.


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


Re: [Tagging] landcover=asphalt ; landuse=highway

2018-07-13 Thread Bryan Housel
From what I remember people are already using  `area:highway=*` for detailed 
street area mapping.
https://taginfo.openstreetmap.org/keys/area%3Ahighway 


I would think `landuse=highway` would work kind of like `landuse=railway`, used 
to map a right of way corridor, not the actual asphalt surface.

Thanks, Bryan



> On Jul 13, 2018, at 9:36 AM, Leo Gaspard  wrote:
> 
> These tags has already been put forth in the landcover proposal [1], but
> I was just pointed to [2] where a user complained (rightfully) that the
> shape of the road on OSM mismatched the shape of the actual road.
> 
> As a consequence, I think we should add the `landuse=highway` in the
> list of officially-defined tags, especially given it is already used
> ~10k times.
> 
> And encourage putting the relevant polygon inside the associatedStreet,
> because that would make sense.
> 
> And potentially also add landcover=asphalt, because why not?
> 
> FTR, google maps already has a similar feature, that is visible eg. at [3]
> 
> What do you think about this?
> 
> 
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/landcover
> 
> [2] https://www.openstreetmap.org/note/1387860
> 
> [3]
> https://tools.geofabrik.de/mc/#18/35.8820/139.5169=2=mapnik=google-map
> 
> ___
> 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] shop=discount

2018-06-26 Thread Bryan Housel
> Meanwhile, there probably is a need to tag a kind of store that is sometimes 
> referred to as a discount store.  I'm
> thinking of the likes of Costco or Sam's Club.  They're essentially 
> wholesalers operating on a cash and carry basis
> and which are open to the public, not just retailers (but you may need to pay 
> a membership fee).  Sometimes known

`shop=wholesale` is what people are using for stores like Costco and Sam’s Club:
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dwholesale 


Thanks, Bryan

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


Re: [Tagging] drop covered=booth?

2018-06-24 Thread Bryan Housel
> On Jun 24, 2018, at 7:05 PM, Martin Koppenhoefer  
> wrote:
> Ok..
> I’ve decided after talking to a few more people about this that I’m going to 
> just support things in iD the best I can, and pull back from tagging 
> discussions.  
> 
> "just support things" sounds fine, if this means adding support for 
> established tags. I would not consider introducing new tags to be covered by 
> "supporting things", or would you? What are your criteria to determine an 
> "established tag"?


I’ll decide on a case-by-case basis.  The main goals are to let people map what 
they want to map, and to make it easy for novice users to figure out.

Thanks, Bryan

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


Re: [Tagging] drop covered=booth?

2018-06-24 Thread Bryan Housel
Ok..
I’ve decided after talking to a few more people about this that I’m going to 
just support things in iD the best I can, and pull back from tagging 
discussions.  

Thanks, Bryan



> On Jun 24, 2018, at 11:42 AM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> sent from a phone
> 
>> On 24. Jun 2018, at 16:19, Bryan Housel  wrote:
>> 
>> I can’t be any more clear than this:
>> 
>> I will support `covered=yes/no` as a checkbox.
>> I will support `booth=*` as a dropdown
>> I won’t support `covered=booth` .  
> 
> 
> that’s all fine, but you should not retag the objects and should not change 
> the wiki as proposed above, it is not justified by the numbers and the way 
> things currently are tagged. Do you read what I write? You proposed to retag 
> 5000+ objects to a tag that is now 134 times used and where the value is 
> essentially an outlier among the other values for the key.
> 
> cheers,
> Martin
> ___
> 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] drop covered=booth?

2018-06-24 Thread Bryan Housel
> On Jun 24, 2018, at 9:47 AM, Martin Koppenhoefer  
> wrote:
> 
> what about modifying all booth=yes on telephones to covered=booth ?



No.  That’s the exact opposite of what I’m trying to achieve.  I feel like you 
might not have read very carefully any of the emails that I’ve sent on the 
subject.

I can’t be any more clear than this:

I will support `covered=yes/no` as a checkbox.
I will support `booth=*` as a dropdown
I won’t support `covered=booth` .  

I’m not going to add special code to iD to make the `covered=yes/no` checkbox 
field (which is used on many other presets) do a special and unnecessary thing 
only when it is used on the telephone preset. 


Thanks, Bryan


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


Re: [Tagging] emergency=first_aid_kit

2018-06-23 Thread Bryan Housel
> On Jun 23, 2018, at 10:32 PM, Graeme Fitzpatrick  
> wrote:
> 
> There should also be a separate page for first aid facility, if you're not 
> busy :-)

I still think a staffed facility should be something under `healthcare=*` - 
there is lots on that page already.


> Mentioned on the lifeguard thread the other day that the whole Emergency area 
> has been getting cleaned up for the last 4 years!
> As we've seen over this last couple of weeks, it really does need it.
> How do we stir up the cleaning process - comment on the discussion page / 
> start a thread here / ???

Yes!  Start a thread here on the mailing list for general discussion 
I’d avoid using the discussion pages - they have a very limited audience.

If it results in something that somebody can actually do, let’s track it on 
this repo: https://github.com/osmlab/osm-tagging 

I’m already starting to capture some issues there for pages that need cleanup.

thanks, Bryan


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


Re: [Tagging] emergency=first_aid_kit

2018-06-23 Thread Bryan Housel
> Would you object if I changed the page to emergency=first_aid_kit for 
> example?? 

I would not mind at all -  `emergency=first_aid_kit` was what I suggested 
originally.
Someone else made that wiki page and I don’t know why they called it that.

Anyway I just moved it to `emergency=first_aid_kit`
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfirst_aid_kit 



Thanks, Bryan






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


Re: [Tagging] emergency=first_aid

2018-06-23 Thread Bryan Housel
> Err .. proposals can be for anything, including sub tags. There should be 
> more of it.
> Things like the sub tag 'sales' under motorcycle shops could have been 
> avoided if that had come to the tagging group. 

I would never waste people’s time by writing a proposal for something so simple 
as a first aid kit.
Notifying the tagging list seems like more than enough process for introducing 
a new tag.


> Something? If that something is poor then is is not an accomplishment. 

You are calling my work poor?  Improve it then.
We’ve been talking about this tag for over a week.


> The value of 'first_aid' could be applied to a 'first aid room' ... 
> https://en.wikipedia.org/wiki/First_aid_room 
> '

The tag is for first aid kits, not rooms.


> Most kits are portable, many of them are designed to be portable. are these 
> included? No information on the OSMwiki page. 

Yes, same as emergency=defibrillator 
  - they are 
portable but generally attached to walls.


> 73 is not a status of  'in use' 

So change what it says.  


Thanks ,Bryan

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


Re: [Tagging] drop covered=booth?

2018-06-23 Thread Bryan Housel
> On Jun 23, 2018, at 6:00 PM, Warin <61sundow...@gmail.com> wrote:
> 
>> We’re not adding `booth=yes` to all phones.  Just the ones that
>> - don’t already have a `booth=*` tag and
> 
> That is not right. If they don't have a booth=* tag then don't think that 
> these all have a booth.
> So I would not add a tag here that maybe wrong.
> 
>> - do have a `covered=booth` tag
> 
> This is correct .. they have a booth so adding booth=yes is correct.


It sounds like you are very confused.

I’ll try again.

The only features I’m modifying have the tags `amenity=telephone` and 
`covered=booth`.
I will change `covered=booth` to `covered=yes`
I will add a tag `booth=yes` but only if there is not already an existing 
`booth*` tag.

The reason I’m doing this is so that we can offer users a `covered` checkbox 
for the telephone preset in iD.
This checkbox really wants to assign values like `yes` and `no` -- not `booth`.
Make sense?

Thanks, Bryan


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


Re: [Tagging] drop covered=booth?

2018-06-23 Thread Bryan Housel
> Somebody has already posted a picture to the list of a public phone with no 
> hood, no booth, and no cover, so
> adding booth=yes to all phones could be an error.

Are you being deliberately obtuse?   

We’re not adding `booth=yes` to all phones.  Just the ones that
- don’t already have a `booth=*` tag and
- do have a `covered=booth` tag

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


Re: [Tagging] drop covered=booth?

2018-06-23 Thread Bryan Housel
Looks like we can wrap up discussion on this.
Per Paul Allen’s suggestion, mappers can continue use `covered=yes` for 
telephones with a hood.
Opened https://github.com/osmlab/osm-tagging/issues/8 
<https://github.com/osmlab/osm-tagging/issues/8>  to track next actions for 
this.

"Consensus on list is that covered=booth offers no additional information over 
booth=* and conflicts with existing semantics for covered=yes/no. We'll replace 
all instances of covered=booth with covered=yes and add a booth=yes to any 
features that don't already have a booth tag.”

Thanks, 
Bryan




> On Jun 19, 2018, at 9:41 AM, Bryan Housel  wrote:
> 
> Sounds good to me.
> We can leave the thread open a few more days to see if anyone cares that much 
> about `covered=booth`.
> I think 5 days is plenty.
> 
> If nobody is using it, I’ll open an issue on 
> https://github.com/osmlab/osm-tagging <https://github.com/osmlab/osm-tagging> 
> on or around June 23 to start the cleanup..
> 
> As always, looking for volunteers to do the actual work of replacing the tags 
> and cleaning up the wiki.
> 
> Thanks, Bryan
> 

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


Re: [Tagging] emergency=first_aid

2018-06-23 Thread Bryan Housel
> On Jun 23, 2018, at 10:58 AM, Martin Koppenhoefer  
> wrote:
> +1, if you want to describe the position of a first aid kit, a sensible tag 
> seems emergency=first_aid_kid
> For a staffed location where you go for first aid, emergency=first_aid seems 
> ok (I’d rather use something more verbose like first_aid_station or facility 
> to avoid confusing them with the kits).

Let’s just keep this scoped to first aid kits.  If it was staffed location, I’d 
probably use something under `healthcare=*`  (maybe `clinic`)  
https://wiki.openstreetmap.org/wiki/Key:healthcare#Values 



> Generally, it is not OK to set up wiki pages for rarely used tags out from 
> nothing, they should be added as proposals to make it easier for 
> inexperienced mappers to distinguish established tags from adhoc drafts 
> without consolidated content.

Yes it is OK to
- invent a new tag value and 
- setup a wiki page for it and 
- notify the tagging list.  

People do this all the time (maybe without notifying the tagging list, but 
let’s encourage more of that).

Proposals should only be for when we’re inventing a new toplevel key or 
introducing a change that affects a lot of things (like PTv2, healthcare, etc). 
 I see a lot of proposal misuse and proposals that shouldn’t be proposals in 
the first place - let’s stop doing this.


FWIW, someone else already made the wiki page.  I’ve cleaned it up and added 
the preset to iD.

> https://wiki.openstreetmap.org/wiki/Tag:emergency=first_aid 
> 
So that’s the tag.  Be glad we accomplished something!

Thanks,  Bryan


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


Re: [Tagging] iD presets

2018-06-21 Thread Bryan Housel
> On Jun 21, 2018, at 6:16 AM, Christoph Hormann  wrote:
> 
> Then why do you object to Frederik's idea of separating the tagging 
> presets from editor development and give up control over the decisions? 

I offered to do exactly this a few years ago:
https://github.com/osmlab/editor-presets/pull/2 

Nobody cared, so it sat and eventually went stale over a few months.

I wouldn’t do it today.  

Looking back on the iD changelogs 
 (and scanning 
through the still open issues) there are lots of usability items that affect 
the preset system.
Some recent examples of things I couldn’t do (quickly) if the presets were an 
external project:

* We changed all the icons to support multiple iconsets 
  and this meant that I needed 
to change all the icon names in all the presets.
* We implemented a check to support min and max field values 
, and it meant that I needed 
to go through all the presets and add some properties to certain ones.
* We renamed the field label from “Phone” to “Telephone” 
 so that a user can type 
either value in the Add field dropdown.

Usability and speed of development are very important to me, and these are 
things that would suffer if I split the presets off into a separate project.


> I am glad you work on improving possibilities for choice of presets and 
> this could over time be used to allow alternatives - like converting 
> the JOSM presets (which already includes a lot of specialized add on 
> preset collections) or managing diverse independent preset collections.  
> This is IMO the best way to go ahead here.

Yes allowing people to override the presets at runtime is something I want to 
add.  (I almost built it at the hackathon.)

For the curious, the somewhat tricky part about this is the bootstrap process.  
Currently, presets in iD are ready at startup and translations are loaded in 
later.  If a user specifies a replacement preset file, we need to delay some 
code until the browser has fetched everything.


Just going to cut my reply off here.  There was some vague stuff in your 
message about “poisoning OSM” that didn’t seem to be a serious question.  Also 
for the record, I’m fine with either method of mapping runways (I prefer to map 
them as a 2 node way myself).  iD supports both methods (drawn as a linear way 
or as a closed way area).  

If you don’t use iD, I encourage you to try it out..
Please report any specific bugs for feature requests on our issue tracker:  
https://github.com/openstreetmap/iD   


Thanks, Bryan

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


Re: [Tagging] Be the change you want to see in the world - was: emergency=lifeguard

2018-06-20 Thread Bryan Housel
> On Jun 20, 2018, at 5:21 AM, Martin Koppenhoefer  
> wrote:
> this is what I understood from the messages you recently sent here, e.g.: "We 
> have too many tags for different kinds of lifeguards.  This is too confusing. 
> I don’t want to have to show all these choices to iD users. ... Let’s just 
> use one tag `emergency=lifeguard`" (note that this tag has 6 / six uses and 
> its use is conflicting with documented and more established tags because of 
> overlap and using the same key) .

I wouldn’t call the existing uses of these lifeguard tags “established”.  I’d 
put the threshold for established at around 2000 uses.  (or, more than a single 
person could change easily with level0 or JOSM).


> You also wrote: "It kind of makes one question whether a community edited 
> wiki is a good way to standardize a tagging scheme intended to produce a 
> coherent mapping dataset.  Bold suggestion: maybe the people who write the 
> tools should just get together over beers and decide what all the tags should 
> be.  I’ll buy!"

Still offering to buy!  Will you be at SOTM in Milan?


> I appreciate you recognize there should be a process, but I wouldn't call 
> your current way of interacting with the community an involvement in the 
> decision making. You make the decisions and then communicate here what it is 
> and ask to "please update the wiki". 

Hopefully you read closely my previous response to Christoph, look through the 
recent iD changelogs, and change your mind about that.. The process for adding 
presets to iD is very much community driven.  


> At least  the old process lead us until here, I agree with Frederik that 
> "taking the lead on tagging" is clearly overstepping your mandate, in the 
> most sensitive and essential field.

Again, I don't have a mandate to overstep.  I’m a mapper who loves OSM like 
everyone else here.


> The operation of the OSMF editor should not be in conflict with the OSMF 
> mission. 

iD is not an “OSMF editor”.  I literally have nothing to do with OSMF.  They’re 
not asking me for feature requests.  Pretty sure my work supports their mission 
anyway.   (You might just as well call iD the “HOT editor”).


> can you please clarify, do you mean debating tags is never meaningful work, 
> or whether it is not meaningful to debate them on a mailing list?

I don’t feel like the epic landcover vs landuse thread was meaningful.   But 
hopefully people feel like the threads I’ve started in the past week have been 
meaningful.  At least we have some tagging improvements queued up on 
https://github.com/osmlab/osm-tagging  . 
 Looking for some volunteers to help out there (you don’t have to be an editor 
developer to make a difference).


Thanks, Bryan



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


Re: [Tagging] iD presets

2018-06-20 Thread Bryan Housel
Hey Christoph - You make some really interesting points in your email.  Rather 
than replying point by point, I’m going to pick out a few phrases that stood 
out.

It sounds like I need to do a better job of explaining...

‍  “How a tag becomes a preset in iD”

First - and this is something that a lot of people seem misinformed about - I 
mostly don’t add the presets to iD. 

Check out the iD changelog going back several releases and you can see all the 
preset work that we’ve done:
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#whats-new 


We are very proud of the changelog.  I try to make this document the sort of 
thing that anybody can read.  When new releases of iD are pushed out, users can 
even see a small  icon in the corner of iD that links to our changelog.  

iD is an open source project that anybody can follow, but I make it a point to 
share our successes, and give shoutouts to our contributors. (If an item does 
not have a “thanks”, it means I did it.)

Each new release in the changelog has a section for “Presets”.  And almost all 
of those items have links to GitHub issues and pull requests which close them.  
You should click through and read some - some things that may surprise you:

1. Most of the people proposing the presets are not me.
2. Most of the people implementing the presets are also not me.
3. I mostly just accept anything that anybody asks for.
4. Every month we add or improve between a handful and a few dozen presets.

A lot of people contribute presets to iD.  It’s actually really easy to do 
(just add some .json files), and a great task for a first time open source 
contributor.

So you said...

> This is IMO - no matter who has this control - in 
> conflict with the fundamental ideas of OSM, that mappers mapping things 
> decide on how to tag things, not the developers of tools used for 
> mapping.  

As I see it, the users of iD and the community are deciding which presets get 
included.  I might recommend a change in what the display name should be, or 
what icon it should have, but I almost never tell someone that they can’t add a 
preset or field (some examples coming up next). 


> If i read you correctly you are unwilling to..
> * establish verifiable principles for decisions about tagging presets in 
> iD that limit use of presets to push subjectively preferred tagging 
> ideas against existing widely accepted practice.


Great segue!
We should list out the “principles for decisions about tagging presets in iD"

1. It should be something that an untrained user can figure out.
This is really the most important rule - it's why I said “no" 
 to biology fields like `taxon` 
or `genus` to the Tree presets.  You'd need to be a botanist to fill these 
correctly, so having these fields in iD would more likely lead to people 
inputting bad data than good data.  Same reason I also said “no” 
 to adding `bic` field to the 
Bank preset, and said “no”  to 
`ref:vatin` for businesses.

2. There should be ideally only one preset for a thing.
It happens sometimes that there are two ways to tag something (`natural=wood` 
vs `landcover=trees`?)  In this case we would probably just go with the most 
common one.  Sometimes we go with a newer less established tag if it is 
possible to also put the legacy tag alongside the new tag (this is the case 
with most of the PTv2 or healthcare presets).  Users get very confused by the 
difference between `amenity=place_of_worship` and `building=place_of_worship`.  
We try to give them cues in the rendering (all buildings render a certain way) 
and the preset text.

3. Presets should be mostly understood everywhere.
This is because iD is used everywhere and translated into dozens of languages.  
There are a few things that don’t translate well, and these tend to be more 
hyper specific kinds of tags.  For example, we didn’t add a preset for 
`memorial=stolperstein`, since this is not a concept that is everywhere.  
Instead we added that word to the existing `historical=memorial` preset as a 
search term, and we provided a dropdown field so that users can easily add 
these.  

Related to being understood everywhere, I try to make sure every preset has a 
short description (that fits in about 300px) and a nice icon.  It should also 
have a decent page on the OSM wiki, because we pull help content from there.

4. Don’t overwhelm with too many options.
There are 100s of kinds of vending machines but we only have dedicated presets 
for about the 20 most popular kinds.

5. Don’t put too many fields on a preset.
We run into this with `amenity=bar` preset but several others too.  People want 
fields for the kind of beers there, and whether they have outdoor seating, and 
whether they offer takeout, and what the wifi password 

Re: [Tagging] emergency=first_aid_kit

2018-06-20 Thread Bryan Housel
Sure, what would help?
Calling it a first_aid_kit? so nobody would get it confused with a staffed 
facility?


> On Jun 20, 2018, at 3:25 PM, Simon Poole  wrote:
> 
> I'm actually not quite happy with the whole thing as it would seem to range 
> from a potentially staffed first aid facility to what you were looking for, a 
> simple first aid kit. In practical terms that would be a rather big 
> difference that should be reflected in the tagging.
> 
> Simon
> 
> Am 20.06.2018 um 19:51 schrieb Bryan Housel:
>> I guess `emergency=first_aid` seems fine (since it aims to replace the 
>> barely used `amenity=first_aid`)
>> 
>> I agree the page looks like a rough draft, but the infobox looks pretty 
>> good.  Thank you for volunteering to clean it up!
>> It should probably be a feature that sits on points only (like 
>> `emergency=defibrillator`) - the “shop outline” stuff doesn’t make sense.
>> 
>> Thanks, Bryan
>> 
>> 
>> 
>>> On Jun 20, 2018, at 1:46 PM, Simon Poole >> <mailto:si...@poole.ch>> wrote:
>>> 
>>> Not to mention first_aid vs first_aid_kit what it is supposed to be now?
>>> 
>>> Am 20.06.2018 um 19:40 schrieb Simon Poole:
>>>> If I may say so the page seems a bit weird. 
>>>> Name on a first aid kit? Draw an area around the shop outline?
>>>> 
>>>> Assuming that are simply C errors, I'll fix things in nobody has any 
>>>> objections.
>>>> 
>>>> Simon
>>>> 
>>>> Am 20.06.2018 um 19:31 schrieb Bryan Housel:
>>>>> Just following up after a week - there wasn’t any significant opposition 
>>>>> and it looks like somebody added this page:  
>>>>> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dfirst_aid 
>>>>> <https://wiki.openstreetmap.org/wiki/Tag:emergency=first_aid>
>>>>> 
>>>>> Thank you!
>>>>> I’ll add the preset to iD and we can consider this one closed 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jun 11, 2018, at 12:08 AM, Bryan Housel >>>>> <mailto:bhou...@gmail.com>> wrote:
>>>>>> 
>>>>>> I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency 
>>>>>> <https://wiki.openstreetmap.org/wiki/Key:emergency> today.
>>>>>> 
>>>>>> Can we add a tag for `emergency=first_aid_kit` ?
>>>>>> 
>>>>>> thanks, Bryan
>>>>>> 
>>>>>> ___
>>>>>> Tagging mailing list
>>>>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>>>>> https://lists.openstreetmap.org/listinfo/tagging 
>>>>>> <https://lists.openstreetmap.org/listinfo/tagging>
>>>>> 
>>>>> 
>>>>> 
>>>>> ___
>>>>> Tagging mailing list
>>>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>>>> https://lists.openstreetmap.org/listinfo/tagging 
>>>>> <https://lists.openstreetmap.org/listinfo/tagging>
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> Tagging mailing list
>>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>>> https://lists.openstreetmap.org/listinfo/tagging 
>>>> <https://lists.openstreetmap.org/listinfo/tagging>
>>> 
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/tagging 
>>> <https://lists.openstreetmap.org/listinfo/tagging>
>> 
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging 
>> <https://lists.openstreetmap.org/listinfo/tagging>
> 
> ___
> 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] emergency=fire_alarm , emergency=stop_button

2018-06-20 Thread Bryan Housel
It’s been a week on this also with no further discussion and general consensus 
that these things are ok.
Looking for volunteers to update wiki and cleanup tags for:

`emergency=fire_alarm`(existing page at 
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_alarm_box 
<https://wiki.openstreetmap.org/wiki/Tag:emergency=fire_alarm_box> needs to be 
moved)
https://github.com/osmlab/osm-tagging/issues/5 
<https://github.com/osmlab/osm-tagging/issues/5>


`emergency=stop_button`
https://github.com/osmlab/osm-tagging/issues/6 
<https://github.com/osmlab/osm-tagging/issues/6>


Thanks, Bryan



> On Jun 11, 2018, at 10:53 AM, Bryan Housel  wrote:
> 
> Ok cool
> 
> So we have
> `emergency=fire_alarm`   (for both indoor pull and outdoor box types, invent 
> a sub tag if needed to distinguish)
> and
> `emergency=stop_button`
> 
> Who wants to add these pages?
> I’ll add presets for iD this week if we can just move this forward and wrap 
> up the discussion.
> 
> 
> Thanks, Bryan
> 
> 
> 
> 
>> On Jun 11, 2018, at 10:50 AM, > <mailto:osm.tagg...@thorsten.engler.id.au>> 
>> > <mailto:osm.tagg...@thorsten.engler.id.au>> wrote:
>> 
>> And many other places, yes… that’s why I was surprised to see that 
>> emergency=stop_button has only been used a single time worldwide and there 
>> don’t seem to be any other similar values in the emergency key.
>>  
> 

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


Re: [Tagging] emergency=first_aid_kit

2018-06-20 Thread Bryan Housel
I guess `emergency=first_aid` seems fine (since it aims to replace the barely 
used `amenity=first_aid`)

I agree the page looks like a rough draft, but the infobox looks pretty good.  
Thank you for volunteering to clean it up!
It should probably be a feature that sits on points only (like 
`emergency=defibrillator`) - the “shop outline” stuff doesn’t make sense.

Thanks, Bryan



> On Jun 20, 2018, at 1:46 PM, Simon Poole  wrote:
> 
> Not to mention first_aid vs first_aid_kit what it is supposed to be now?
> 
> Am 20.06.2018 um 19:40 schrieb Simon Poole:
>> If I may say so the page seems a bit weird. 
>> Name on a first aid kit? Draw an area around the shop outline?
>> 
>> Assuming that are simply C errors, I'll fix things in nobody has any 
>> objections.
>> 
>> Simon
>> 
>> Am 20.06.2018 um 19:31 schrieb Bryan Housel:
>>> Just following up after a week - there wasn’t any significant opposition 
>>> and it looks like somebody added this page:  
>>> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dfirst_aid 
>>> <https://wiki.openstreetmap.org/wiki/Tag:emergency=first_aid>
>>> 
>>> Thank you!
>>> I’ll add the preset to iD and we can consider this one closed 
>>> 
>>> 
>>> 
>>>> On Jun 11, 2018, at 12:08 AM, Bryan Housel >>> <mailto:bhou...@gmail.com>> wrote:
>>>> 
>>>> I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency 
>>>> <https://wiki.openstreetmap.org/wiki/Key:emergency> today.
>>>> 
>>>> Can we add a tag for `emergency=first_aid_kit` ?
>>>> 
>>>> thanks, Bryan
>>>> 
>>>> ___
>>>> Tagging mailing list
>>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>>> https://lists.openstreetmap.org/listinfo/tagging 
>>>> <https://lists.openstreetmap.org/listinfo/tagging>
>>> 
>>> 
>>> 
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/tagging 
>>> <https://lists.openstreetmap.org/listinfo/tagging>
>> 
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging 
>> <https://lists.openstreetmap.org/listinfo/tagging>
> 
> ___
> 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] emergency=first_aid_kit

2018-06-20 Thread Bryan Housel
Just following up after a week - there wasn’t any significant opposition and it 
looks like somebody added this page:  
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dfirst_aid 
<https://wiki.openstreetmap.org/wiki/Tag:emergency=first_aid>

Thank you!
I’ll add the preset to iD and we can consider this one closed 



> On Jun 11, 2018, at 12:08 AM, Bryan Housel  wrote:
> 
> I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency 
> <https://wiki.openstreetmap.org/wiki/Key:emergency> today.
> 
> Can we add a tag for `emergency=first_aid_kit` ?
> 
> thanks, Bryan
> 
> ___
> 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] iD presets - was: emergency=lifeguard

2018-06-19 Thread Bryan Housel
> On Jun 19, 2018, at 10:59 AM, Frederik Ramm  wrote:
> 
> Hi,
> Perhaps it would make sense to treat the iD editor and the tagging
> presets it uses as two different projects that are conceptually separate
> enough so that the tagging presets as rolled out on osm.org can be
> curated by a group that is separate from the editor writers?

I used to think that splitting off the iD presets into their own project was a 
good idea, but I’ve changed my mind in the past few years.  I don’t think the 
OSM community is particularly good at inventing tags, I can’t think of anyone 
that I would trust to turn the presets over to, and it’s not like we have a lot 
of people stepping up to lead another OSM software project.  People will surely 
take exception to this, but that’s the uncomfortable truth as I see it. 

I still think that tagging should ultimately be driven by the community, but 
that people working with software (editors like iD/JOSM, styles like osm-carto, 
routers like OSRM, data consumers) should not be afraid to speak up about a 
problematic tagging scheme before it is too late to change it.


> I don't think designing tags is what the editor writers should do, that
> would clearly be overstepping their mandate.

We probably disagree on what my “mandate” is then.   That’s ok.

My goal is to make it so that anybody can use iD to contribute meaningfully to 
OSM.  Mostly I want people to enjoy mapping and stay engaged.  I like to say 
that the point of iD is to “convert people who don’t care about maps into 
people who do care about maps.”  I don’t care about tags as much as you 
probably think I do.


Some things that matter to me:

If a mapper wants to add a lifeguard station, there should be one lifeguard 
preset (and additional fields to supply more details if known).  Not 4 
lifeguard presets.

If a mapper splits a way, they should not be silently breaking the 
`transit:lanes` tags added by other contributors.  If someone is just getting 
started with their editing, and they split a way, they should not get an angry 
changeset discussion that they don’t understand.

When a mapper adds a phone booth preset, the tags should already be set up for 
them according to the best practice on the wiki.  We already have a checkbox 
field for `covered=yes/no` and some code to render covered ways under other 
stuff.  `covered=booth` is special (doesn’t work like other uses of `covered`) 
and I’d like to avoid adding custom code for it if possible.  It’s nice to ask 
people first before just closing an issue as ‘wontfix’.

When a mapper adds a picnic shelter - do we assume it is a building, or do we 
ask the user to add a `building=*` tag.  Do we render it like other buildings?  
 Users should be able to add picnic shelters without reading pages of wiki and 
tagging list guidance.

I can think of dozens more, but we’ll probably get to those eventually.  Stay 
subscribed to this list if you want to talk through lots more interesting 
tagging conundrums. 

Thanks for listening,
Bryan


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


Re: [Tagging] emergency=lifeguard

2018-06-19 Thread Bryan Housel
> This is not the first time, and you have stated more than once your idea of 
> tag creation and endorsement is top down, with the software maintainer 
> deciding the tags on the input side, sweeping away the confusing plurality of 
> comunity created tags. 

That’s not really what I think - are you sure I said that?

I think the community should continue to invent tags, but if the tags that 
aren’t very good (as decided by people who work on software), I think we should 
have a process for replacing them.  You're right that this has been going on 
for a while, but starting now I’m trying to involve the community more rather 
than just changing things in the editor.


> There is no reason you shouldn't properly document the changes in tagging 
> recommendation in the wiki via a proposal like all other mappers and 
> developers do.

Proposals don’t work - see `transit:lanes`.. see the long thread about 
`landcover vs landuse`.  etc. etc.
This is the main reason I’ve decided to step up and take the lead on these 
things. 
The old process wasn’t working. 


> You won't be able to argue that it takes less time or is more efficient to 
> discuss this on the tagging mailing list.

Truer words were never spoken..  I expect this to be a bit of a time sink, but 
I’m hoping some more people will step up and do some of the work necessary (and 
no, debating tags on a mailing list is not meaningful work).

I’m happy to do the work on the editor side, but we need people to work on 
actual tag migrations (either manually or via automated scripts), and we need a 
dedicated corps of volunteers who care about making the wiki simple and 
accurate. 


Thanks Bryan


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


Re: [Tagging] emergency=lifeguard

2018-06-19 Thread Bryan Housel
Basically, yeah 


> On Jun 19, 2018, at 9:47 AM, Andy Townsend  wrote:
> 
> On 19/06/2018 14:37, Bryan Housel wrote:
>> Yes it was settled a week ago
>> The migration is being discussed here: 
>> https://github.com/osmlab/osm-tagging/issues/1
>> This thread can end now :)
>> 
>> Thanks, Bryan
>> 
> 
> So as well as being lead developer on an OSM editor you reckon that you've 
> not been getting enough ad hominem attacks and have appointed yourself OSM 
> tagging dictator as well?Clearly someone who really doesn't like the 
> quiet life :)
> 
> 
> 
> ___
> 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] `amenity=shelter` implies `building=yes`?

2018-06-19 Thread Bryan Housel
FYI I closed this issue in iD yesterday.  We now provide a field to let users 
decide whether to treat `amenity=shelter` as a building or not.

Thanks all for your input!
Bryan




> On Jun 17, 2018, at 12:45 AM, Bryan Housel  wrote:
> 
> Does `amenity=shelter` imply `building=yes`?
> 
> The osm wiki page does not suggest `building=*` as a “tag to use in 
> combination”
> https://wiki.openstreetmap.org/wiki/Tag:amenity=shelter 
> <https://wiki.openstreetmap.org/wiki/Tag:amenity=shelter>
> 
> But most other features which are closed-way structures need the `building=*` 
> tag.  I know it’s a tag used by 3D mapping.  It seems like for consistency, 
> we should add an explicit `building=*` tag.
> 
> Asking for https://github.com/openstreetmap/iD/issues/5084 
> <https://github.com/openstreetmap/iD/issues/5084>
> 
> thanks Bryan
> 

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


Re: [Tagging] drop covered=booth?

2018-06-19 Thread Bryan Housel
Sounds good to me.
We can leave the thread open a few more days to see if anyone cares that much 
about `covered=booth`.
I think 5 days is plenty.

If nobody is using it, I’ll open an issue on 
https://github.com/osmlab/osm-tagging <https://github.com/osmlab/osm-tagging> 
on or around June 23 to start the cleanup..

As always, looking for volunteers to do the actual work of replacing the tags 
and cleaning up the wiki.

Thanks, Bryan




> On Jun 18, 2018, at 4:21 PM, Paul Allen  wrote:
> 
> On Mon, Jun 18, 2018 at 9:00 PM, Bryan Housel  <mailto:bhou...@gmail.com>> wrote:
> from https://github.com/openstreetmap/iD/issues/5088 
> <https://github.com/openstreetmap/iD/issues/5088>
> 
> Proposal:
> I’d like to drop `covered=booth` as a suggested tag, as it’s superfluous.  If 
> the telephone feature has `booth=yes` or `booth=K6` you know it’s a booth.  
> Then we’re not repurposing the `covered=*` for a thing that it doesn’t 
> normally do in other situations and isn’t documented on the main `covered` 
> page.
> 
> The only possible problem with this is that many public phones in the US have 
> an acoustic hood which shields
> the phone from rain and may provide a degree of rain protection to the user.  
> In which case the acoustic hood
> provides cover, just no as much as a booth.
> 
> Then again, I've never seen an outdoor public phone that isn't in a booth 
> also lack an acoustic hood.  So should
> mappers and consumers assume a hood is present unless booth is specified?  
> Except I can conceive of a phone
> in a building passage having neither a booth nor a hood (seems unlikely, but 
> possible).
> 
> Otherwise, I have no problems with the change.  By all means drop an 
> inappropriate, repurposed tag for something
> better.  Once we're sure we're not going to hit further problems because we 
> didn't think of all use cases.
> 
> If we do go down this route, then I think an automated edit is justified 
> which drops covered=booth where booth=* is
> specified and replaces covered=booth with booth=yes where booth isn't 
> specified.
> 
> -- 
> Paul
> 
> ___
> 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] emergency=lifeguard

2018-06-19 Thread Bryan Housel
Yes it was settled a week ago
The migration is being discussed here:  
https://github.com/osmlab/osm-tagging/issues/1 
<https://github.com/osmlab/osm-tagging/issues/1>
This thread can end now :)

Thanks, Bryan




> On Jun 19, 2018, at 9:27 AM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> 2018-06-19 15:14 GMT+02:00 Bryan Housel  <mailto:bhou...@gmail.com>>:
> Thank you for checking! 
> I guess those can be`emergency=lifeguard + lifeguard=base`
> (what was decided before)
> 
> 
> "decided"? 
> I suggest you use a different key than "emergency" for this new tag you 
> intend to introduce via iD presets, the above would conflict with the 
> established tags. E.g. use "amenity", so that both systems can coexist.
> 
> Cheers,
> Martin
> 
> ___
> 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] emergency=lifeguard

2018-06-19 Thread Bryan Housel
Thank you for checking! 
I guess those can be`emergency=lifeguard + lifeguard=base`
(what was decided before)


> On Jun 19, 2018, at 8:39 AM,  
>  wrote:
> 
> I just randomly checked out 20 of the places currently tagged with 
> emergency=lifeguard_base and none of them looked like something for which 
> office=lifeguard would seem appropriate, but all of them looked like what I 
> expected, a place where you can find lifeguards, just with more equipment and 
> infrastructure than a lifeguard_tower.
> 
>> -Original Message-
>> From: marc marc 
>> Sent: Tuesday, 19 June 2018 22:24
>> To: tagging@openstreetmap.org
>> Subject: Re: [Tagging] emergency=lifeguard
>> 
>> Le 19. 06. 18 à 13:56, Bryan Housel a écrit :
>>>> the lifeguard base is defined for storage and administration
>> 
>>> It could be `office=lifeguard`
>> 
>> that look like a good idea at least for the administration
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] emergency=lifeguard

2018-06-19 Thread Bryan Housel


> On Jun 19, 2018, at 7:41 AM, Martin Koppenhoefer  
> wrote:
> 
> 2018-06-19 11:17 GMT+02:00 Andrew Harvey  >:
> Martin, which part? The whole reason this discussion started is because Bryan 
> wants to offer a way to tag a lifeguard facility iD without forcing users to 
> choose the exact kind of lifeguard facility. At the moment with the current 
> documentation on the wiki you need to choose what type, and can't say it's a 
> generic.
> 
> My suggestion for this case is to add lifeguard/s=yes as property to the 
> guarded object or part of the object that is guarded / supervised, or maybe 
> supervised:lifeguard=yes ?

You can do this too, I won’t complain.


> If Bryan wants to propose a new "neutral" lifeguard facility which does not 
> bear any information in the first level about the kind of feature on the 
> ground (in contrast to the system that has evolved through the comunity 
> process), I suggest he sets up a proposal. There are currently only 6 uses of 
> emergency=lifeguard


The lifeguard tags that have "evolved through the community process" are flawed 
and not really used much, so we’re changing them. 
(I will not be doing a proposal, but posting to tagging mailing list seems 
nicer than just changing things)

going forward:

`emergency=lifeguard`
`lifeguard=*`   (tbh I dont care what values go here, base, place, space, 
whatever)


> water_rescue_station vs. lifeguard_base
> 
> there are 216 emergency=water_rescue_station which to me seems a pretty self 
> explanatory tag to indicate a somehow permanent presence of lifeguards with 
> some infrastructure. The wiki says it is in proximity to the water surface it 
> is guarding. The other tag is emergency=lifeguard_base with 240 uses and 
> defined as the "main building" where the administrative work gets done and 
> equipment and vehicles are "stored". 

It’s fine for people to keep tagging these but I probably wouldn't add a preset 
for this in iD.


> as the lifeguard base is defined for storage and administration, it doesn't 
> seem to fit with the expectations one would have from a potential new 
> emergency=lifeguard. 

It could be `office=lifeguard` then.  Let’s get rid of them.


Thanks, Bryan

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


Re: [Tagging] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

2018-06-18 Thread Bryan Housel
> On Jun 18, 2018, at 8:16 PM, Paul Allen  wrote:
> 
> On Tue, Jun 19, 2018 at 12:36 AM, Eugene Alvin Villar  > wrote:
> 
> Just to comment on the Microsoft side angle here….


Please try to stay on topic. 
We’re not going to change our approach to GitHub anytime soon.
If you don’t want to discuss tagging, please follow the link at the bottom of 
this message to unsubscribe.

Thanks, Bryan

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


Re: [Tagging] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

2018-06-18 Thread Bryan Housel
> On Jun 18, 2018, at 5:27 PM, Frederik Ramm  wrote:
> 
> Jokes aside, there are many serious reasons why good old-fashioned
> mailing lists should be the mainstay of important communication in OSM.

I’m not suggesting to replace the mailing list.  As you can probably tell form 
the past week, I’ve significantly stepped up my participation.  I will happily 
take the lead on tagging discussions if that’s what it takes to prevent another 
`transit:lanes`.


> So yes, +1 to keeping the discussion on email - documenting results on
> Github is ok, but trying to move the decision-making there would be
> problematic.

Yep, also +1 to keeping everything on the tagging list.  The Github repo is to 
track what actual work is being done and by whom.  (Please tag yourself if you 
see something you want to help with.)

Right now the only GitHub issue is to fix the `emergency=lifeguard` situation, 
which we’ve already reached consensus on.

Thanks, Bryan


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


[Tagging] drop covered=booth?

2018-06-18 Thread Bryan Housel
from https://github.com/openstreetmap/iD/issues/5088 


`covered`, traditionally:
Someone has asked me to add a `covered=booth` field to the telephone preset.
I’m pushing back on the request slightly because `covered=*` already has a 
mostly-understood meaning defined here 
https://wiki.openstreetmap.org/wiki/Key:covered 


Generally the tag `covered=*` (usually ‘yes’)  is used to indicate that a 
highway goes under a building part, so that linters and validation tools can 
not flag the crossing as an error..

`covered` for telephones?
The `amenity=telephone` page suggests using `covered=booth` for a phone in a 
booth.
It also suggests adding a `booth=*` tag (again usually ‘yes’, but may indicate 
what type of iconic UK phone booth).
https://wiki.openstreetmap.org/wiki/Tag:amenity=telephone 



Proposal:
I’d like to drop `covered=booth` as a suggested tag, as it’s superfluous.  If 
the telephone feature has `booth=yes` or `booth=K6` you know it’s a booth.  
Then we’re not repurposing the `covered=*` for a thing that it doesn’t normally 
do in other situations and isn’t documented on the main `covered` page.

Thoughts?

Thanks, Bryan

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


Re: [Tagging] `amenity=shelter` implies `building=yes`?

2018-06-18 Thread Bryan Housel
Thanks for clarifying Jo - I think this is all ok as long as we give users the 
option to say whether they think their `amenity=shelter` is a building or not.  
 For the bus shelters I could see it as either way but would not override a 
local mapper’s choice.

Maybe we should start a separate thread for “what is a `building=*` really” 
because this is something I see frequent confusion over.

Thanks, Bryan



> On Jun 18, 2018, at 10:29 AM, Jo  wrote:
> 
> shelter=yes on a highway=bus_stop NODE indicates there is a shelter nearby, 
> but says nothing about where it is exactly nor its size.
> 
> amenity=shelter
> shelter_type=public_transport
> 
> on a CLOSEDWAY
> 
> indicates where the shelter is. height is not super important. I guess most 
> are about 2.3m high. If it is considered important I'll go out and measure 
> one and start tagging that on them. But that still doesn't make them 
> buildings. They are more like containers with glass wall panels and a metal 
> roof on a slab of concrete. Relatively easy to move and relatively small in 
> size.
> 
> Polyglot
> 
> Op ma 18 jun. 2018 om 15:28 schreef Bryan Housel  <mailto:bhou...@gmail.com>>:
>> There are also picnic shelters .. here they can have no walls just a roof to 
>> shelter from the heat of the sun or the occasional bit of rain. 
>> e.g. 
>> https://www.riversideca.gov/park_rec/sites/riversideca.gov.park_rec/files/pictures/Picnic%20Shelter%20Hunter%20hobby.JPG
>>  
>> <https://www.riversideca.gov/park_rec/sites/riversideca.gov.park_rec/files/pictures/Picnic%20Shelter%20Hunter%20hobby.JPG>
>> 
> 
> I would tag that as:
> 
> amenity=shelter
> building=roof( <— this tag is really the point of the thread)
> 
> 
>>> The following three are no buildings from my point of view because they
>>> have one wall only. Either the two other walls do not fully stretch from
>>> the ground to the roof or the shelter itself can be removed easily.
>>> 
>>> https://www.mapillary.com/app/?lat=49.08680549357706=9.078079866007897=17=90pd5WuYg8zOk_L8dxLFFQ=photo
>>>  
>>> <https://www.mapillary.com/app/?lat=49.08680549357706=9.078079866007897=17=90pd5WuYg8zOk_L8dxLFFQ=photo>
>>> https://www.mapillary.com/app/?lat=49.08985722389377=9.07931005221235=17=oXQHKqb3Lc3Ae9IXj-5PHw=photo
>>>  
>>> <https://www.mapillary.com/app/?lat=49.08985722389377=9.07931005221235=17=oXQHKqb3Lc3Ae9IXj-5PHw=photo>
>>> https://www.mapillary.com/app/?lat=49.10616167487336=9.121348618135698=17=8xUGL_VKp45sOfd9VW7dUw=photo
>>>  
>>> <https://www.mapillary.com/app/?lat=49.10616167487336=9.121348618135698=17=8xUGL_VKp45sOfd9VW7dUw=photo>
> I would not use `amenity=shelter` at all and instead tag those as 
> https://wiki.openstreetmap.org/wiki/Tag:highway=bus_stop 
> <https://wiki.openstreetmap.org/wiki/Tag:highway=bus_stop>
> 
> highway=bus_stop
> public_transport=platform
> bus=yes
> shelter=yes
> bench=yes
> 
> 
>>> There is building=roof but I would not use it for such shelters. They
>>> are not treated as buildings by the cadastre, why should I do? (If they
>>> are larger and have no walls, they
> Anything that should show up on a 3D map needs a `building` tag and maybe a 
> `height`.
> 
>>> I think that nobody of us knows the whole world and that's why I ask you
>>> not to decide on the default values of the whole world. If local mappers
>>> think that a shelter is a building, they will tag it as such. If they
>>> think that it does not qualify to be a building, they will not add the tag.
> In iD, the things we provide as presets, and how we render those things on 
> the screen influence how people map.
> 
> It sounds like from the discussion that we should not assume that shelters 
> are buildings, and instead provide a field so that mappers can decide.  Once 
> we provide this field, we can expect a lot of people to use it.  (I’m trying 
> to engage the tagging list a lot more so that people feel consulted when I 
> change things in iD.)
> 
> Thanks, Bryan
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging 
> <https://lists.openstreetmap.org/listinfo/tagging>
> ___
> 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] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

2018-06-18 Thread Bryan Housel
> On Jun 17, 2018, at 7:34 AM, Andrew Harvey  wrote:
> 
> If the consensus is to change it to emergency=lifeguard + lifeguard=*, then I 
> think this needs to be changed in:
> 
> 1. The wiki
> 2. Put forward a proposal to do a mechanical edit to change the existing tags
> 3. Carry out that mechanical edit
> 4. Add the preset in iD
> 
> I don't think it's far to the people who put the effort in to do a great job 
> on the wiki documentation and those who've been mapping to that accepted 
> tagging per the wiki, to change (4) without us first/while doing 1,2,3.
> 
> I think only then we can propose to osm-carto for this to be rendered on the 
> default OSM basemap.


This is great!  Happy to see that people are recognizing that some work (but 
not a lot) needs to happen before we change a tag from one thing to another 
thing.

I’ve created a repo where we can track these things:
https://github.com/osmlab/osm-tagging 

I’ll start opening issues for the things we’ve agreed to and I’ll add an issue 
template so that people can check off the items once they are done and close 
the issue once all the steps are completed.  

The repo can link back to the relevant discussion(s) on the tagging mailing 
list.  I think we should continue to make sure that every change is raised on 
the tagging mailing list for WWIC [1] reasons.

Eventually this repo may also contain code and tools for gaining better 
insights into tagging and making changes to tags.


Thanks Bryan

[1] http://www.ftrain.com/wwic.html 

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


Re: [Tagging] `amenity=shelter` implies `building=yes`?

2018-06-18 Thread Bryan Housel
> There are also picnic shelters .. here they can have no walls just a roof to 
> shelter from the heat of the sun or the occasional bit of rain. 
> e.g. 
> https://www.riversideca.gov/park_rec/sites/riversideca.gov.park_rec/files/pictures/Picnic%20Shelter%20Hunter%20hobby.JPG
>  
> 
> 

I would tag that as:

amenity=shelter
building=roof( <— this tag is really the point of the thread)


>> The following three are no buildings from my point of view because they
>> have one wall only. Either the two other walls do not fully stretch from
>> the ground to the roof or the shelter itself can be removed easily.
>> 
>> https://www.mapillary.com/app/?lat=49.08680549357706=9.078079866007897=17=90pd5WuYg8zOk_L8dxLFFQ=photo
>>  
>> 
>> https://www.mapillary.com/app/?lat=49.08985722389377=9.07931005221235=17=oXQHKqb3Lc3Ae9IXj-5PHw=photo
>>  
>> 
>> https://www.mapillary.com/app/?lat=49.10616167487336=9.121348618135698=17=8xUGL_VKp45sOfd9VW7dUw=photo
>>  
>> 
I would not use `amenity=shelter` at all and instead tag those as 
https://wiki.openstreetmap.org/wiki/Tag:highway=bus_stop 


highway=bus_stop
public_transport=platform
bus=yes
shelter=yes
bench=yes


>> There is building=roof but I would not use it for such shelters. They
>> are not treated as buildings by the cadastre, why should I do? (If they
>> are larger and have no walls, they
Anything that should show up on a 3D map needs a `building` tag and maybe a 
`height`.

>> I think that nobody of us knows the whole world and that's why I ask you
>> not to decide on the default values of the whole world. If local mappers
>> think that a shelter is a building, they will tag it as such. If they
>> think that it does not qualify to be a building, they will not add the tag.
In iD, the things we provide as presets, and how we render those things on the 
screen influence how people map.

It sounds like from the discussion that we should not assume that shelters are 
buildings, and instead provide a field so that mappers can decide.  Once we 
provide this field, we can expect a lot of people to use it.  (I’m trying to 
engage the tagging list a lot more so that people feel consulted when I change 
things in iD.)

Thanks, Bryan



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


[Tagging] `amenity=shelter` implies `building=yes`?

2018-06-16 Thread Bryan Housel
Does `amenity=shelter` imply `building=yes`?

The osm wiki page does not suggest `building=*` as a “tag to use in combination”
https://wiki.openstreetmap.org/wiki/Tag:amenity=shelter 


But most other features which are closed-way structures need the `building=*` 
tag.  I know it’s a tag used by 3D mapping.  It seems like for consistency, we 
should add an explicit `building=*` tag.

Asking for https://github.com/openstreetmap/iD/issues/5084 


thanks Bryan

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


Re: [Tagging] iD news - v2.9.0 now with Bing Streetside support

2018-06-16 Thread Bryan Housel
> On Jun 17, 2018, at 12:31 AM, Graeme Fitzpatrick  
> wrote:
> On 17 June 2018 at 14:16, Bryan Housel  <mailto:bhou...@gmail.com>> wrote:
> No, I haven’t seen that.. Can you share the location around where you see 
> them?
> Thanks Bryan
> 
> All over the place!
> https://www.openstreetmap.org/#map=10/-27.5841/153.1775=N 
> <https://www.openstreetmap.org/#map=10/-27.5841/153.1775=N>
> 
> Weren't there a "few" ~5? days ago, when I looked at my home area, but then 
> I've noticed them when looking at maps that people have commented on in the 
> list (Europe, US etc) over these last few days. Went to my home again 
> yesterday & they're there?

Oh, I dont know anything about people adding notes - that’s definitely not iD!


> Another thing I've just noticed as well.
> 
> I saw that you've also recently changed the Australian address format. Just 
> fixing some details & noticed that in edit mode, the suburb name (which has 
> been entered) isn't showing 
> https://www.openstreetmap.org/#map=10/-27.5841/153.1775=N 
> <https://www.openstreetmap.org/#map=10/-27.5841/153.1775=N>, but it is 
> there in normal view only mode https://www.openstreetmap.org/way/563191304 
> <https://www.openstreetmap.org/way/563191304> ?


Yes, we did adjust the Australian address field based on feedback from local 
mappers..
see https://github.com/openstreetmap/iD/issues/5039 
<https://github.com/openstreetmap/iD/issues/5039> for the discussion..


Thanks, Bryan



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


Re: [Tagging] iD news - v2.9.0 now with Bing Streetside support

2018-06-16 Thread Bryan Housel
No, I haven’t seen that.. Can you share the location around where you see them?
Thanks Bryan


> On Jun 17, 2018, at 12:04 AM, Graeme Fitzpatrick  
> wrote:
> 
> 
> 
> 
> On 17 June 2018 at 00:32, Bryan Housel  <mailto:bhou...@gmail.com>> wrote:
> Happy Summer!  
> I just released iD v2.9.0 this week and it’s now available on 
> openstreetmap.org <http://openstreetmap.org/> for editing.  
> 
> Thanks Bryan.
> 
> So are the "Unresolved notes" markers appearing on the map part of your work? 
> 
> Thanks
> 
> Graeme
> ___
> 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] iD news - v2.9.0 now with Bing Streetside support

2018-06-16 Thread Bryan Housel
Happy Summer!  
I just released iD v2.9.0 this week and it’s now available on openstreetmap.org 
 for editing.  If you use street level imagery you 
will like this...


 Bing Streetside now supported
iD now includes a layer for Bing Streetside!  This new layer provides 
360-degree panoramic imagery across large regions of the United States, United 
Kingdom, France, and Spain. Many thanks to Jubal Harpster and the rest of the 
team at Microsoft!
Activate the Bing Streetside layer by opening the Map Data pane (shortcut F)

This pull request includes more details direct from Microsoft clarifying the 
terms of use for mapping with Bing Streetside: 
https://github.com/openstreetmap/iD/pull/5050 



 Mapillary Traffic Signs refresh
iD also made some changes in how we process icons, which resulted in a welcome 
refresh for the Mapillary Traffic Signs layer.  We’ve switched from PNG to SVG, 
so the icons look much clearer, we support many more signs, and the traffic 
sign layer is now supported in all browsers!
Activate the Mapillary Traffic Signs layer by opening the Map Data pane 
(shortcut F)


As always, the update includes several other usability improvements and new 
presets - check out the changelog for all the details.

Changelog: 
v2.9.0 changelog:  
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#290 


Twitter:
v2.9.0 announcement:  https://twitter.com/bhousel/status/1007253540589449216 

Bing Streetside Manhattan: 
https://twitter.com/bhousel/status/1006997683918245888 

Mapillary Street Signs:  https://twitter.com/bhousel/status/1004594196664250369 


Blogs:
Bing Maps:  
https://blogs.bing.com/maps/2018-06/bing-maps-streetside-imagery-now-integrated-into-openstreetmap-id-editor
 

WinBuzzer:  
https://winbuzzer.com/2018/06/15/openstreetmap-id-editor-gets-5-petabytes-of-bing-streetside-imagery-xcxwbn/
 


Reddit:
Thread:  
https://www.reddit.com/r/openstreetmap/comments/8r24pz/id_290_is_live_for_editing_now_you_can_use_bing/
 



Follow and star the iD project on GitHub to show your support:  
https://github.com/openstreetmap/iD 
And follow me on Twitter https://twitter.com/bhousel 
 for the latest iD news. 

Thank you!
❤️ Bryan, and the rest of the  team.

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


Re: [Tagging] I can't support transit:lanes

2018-06-11 Thread Bryan Housel

> On Jun 11, 2018, at 1:17 PM, Mateusz Konieczny  
> wrote:
> 11. Jun 2018 13:09 by bhou...@gmail.com :
> But for right now, can we get that page taken down so people stop tagging it, 
> and have a proper proposal put up and accepted?
> I added 
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2Ftransit=revision=1617128=1617122
>  
> 
Thank you!


> While iD design may exclude flooding user with warnings - why its rendering 
> suggests that for example [building=yes; demolished=yes] is a good idea?
> 

I already told you why here:  
https://github.com/openstreetmap/iD/issues/4501#issuecomment-393726776 


Any feature with any kind of ephemeral tag gets drawn with dashes.

iD also have a special rendering for old style multipolygons, so people can 
clean them up if they want to. Rendering something with dashes doesn’t mean we 
are encouraging people to tag a certain way - it just means “hey mapper, pay 
attention to this thing, there is something interesting about it”.

Please start a separate discussion thread if you want to discuss lifecycle 
tagging. 


Thanks, Bryan

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


Re: [Tagging] I can't support transit:lanes

2018-06-11 Thread Bryan Housel
> You are seriously telling me that if you have two ways that share a node, you 
> are unable to figure out what that node is without having it explicitly 
> listed as a totally redundant member of the relation?

Yes - do you think the via node in a turn restriction is also redundant?  It 
helps me a lot to know whether node joins are allowed around there, or whether 
something will break.

Again see
https://github.com/openstreetmap/iD/commit/87841fc4035c7de9e0f58ca50f05f65723ad5226
 

and
https://github.com/openstreetmap/iD/issues/4921 

for some situations where it’s super helpful to prevent a user from doing 
things to the via node.


Thanks, Bryan

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


Re: [Tagging] I can't support transit:lanes

2018-06-11 Thread Bryan Housel
> Two issues here.
> First, the tag is not “transit:lanes” the tag is “transit” and it can be used 
> with the generalized “:lanes” suffix. 
> There are general rules for the :lanes suffix which can be added to pretty 
> much any tag you would have on a highway were the value could be different 
> for different lanes. See https://wiki.openstreetmap.org/wiki/Lanes 
> 
> It’s the same with e.g. “turn:lanes” (a “turn” key with the “:lanes” suffix) 
> or “access:lanes” (a “access” key with the “:lanes” suffix).

.. none of this matters because the tag can’t go on a way anyhow.


> Second, the “transition” tag is already in use: 
> https://taginfo.openstreetmap.org/keys/transition 
> 
> Now, as far as I can tell, these are pretty much all transition=yes tags on 
> power=tower or power=pole nodes. These seem to be left-overs from a previous 
> tagging scheme, which has been replaced by the use of the 
> location:transition=yes tag (and at 342 vs 13388 uses that seems to have been 
> well accepted by now). 
> So I guess it might be possible to coordinated with people that are involved 
> in power mapping to have these remaining ones retagged to free up the 
> transition key.
> The type=transition value is currently unused, so in that regard the change 
> would be fine.

Ok, so add a new type of relation and call it `type=lane_transition`
https://wiki.openstreetmap.org/wiki/Types_of_relation 



> I agree that this tag when used on ways is problematic from an editor 
> perspective. 
> Though by following pretty simple rules, the editor could prevent the 
> transit(ion):lanes tag on a way from breaking:

Maybe seems simple to you, but I’m not going to do it, and the JOSM and 
Vespucci folks have also already said no too. 


> Transit relations have no via, and they don’t need a via. The from and to way 
> should always touch at exactly one node. Otherwise they are invalid. So you 
> can always determine the “implicit” via node from that.


I’ve already written plenty of code to deal with turn restrictions.  There are 
lots of rules for splitting and joining things to other things depending on 
where the via node is. 

If you are curious, here is a recent commit where I tried to improve iD’s 
handling of this.
https://github.com/openstreetmap/iD/commit/87841fc4035c7de9e0f58ca50f05f65723ad5226
 


In other words if this new relation works like a turn restriction, it’s already 
mostly supported… Otherwise expect basic editing (like splits, joins, 
connections) to break it.

Thanks, Bryan


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


Re: [Tagging] emergency=fire_alarm , emergency=stop_button

2018-06-11 Thread Bryan Housel
Ok cool

So we have
`emergency=fire_alarm`   (for both indoor pull and outdoor box types, invent a 
sub tag if needed to distinguish)
and
`emergency=stop_button`

Who wants to add these pages?
I’ll add presets for iD this week if we can just move this forward and wrap up 
the discussion.


Thanks, Bryan




> On Jun 11, 2018, at 10:50 AM,  
>  wrote:
> 
> And many other places, yes… that’s why I was surprised to see that 
> emergency=stop_button has only been used a single time worldwide and there 
> don’t seem to be any other similar values in the emergency key.
>  

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


Re: [Tagging] I can't support transit:lanes

2018-06-11 Thread Bryan Housel
Amazing, but I’m not surprised that the JOSM devs figured this out years ago :)

OK, so we should probably have a conversation about how a tag like this can 
continue to exist for years with - not just no support but - literally everyone 
who writes software speaking out against it.

But for right now, can we get that page taken down so people stop tagging it, 
and have a proper proposal put up and accepted?
How quickly can the tagging community turn this around?

For the existing data, obviously I’m fine to just delete it, but I imagine 
someone out there would like their work preserved and converted to whatever new 
thing we need to (quickly) agree on.

thanks, Bryan


> On Jun 11, 2018, at 2:06 AM, Mateusz Konieczny  
> wrote:
> 
> For JOSM see https://josm.openstreetmap.de/ticket/11054 
> 
> 
> 11. Jun 2018 06:42 by bhou...@gmail.com :
> I’m not going to add a special rule in iD to warn people if they are 
> splitting a way with a lane transition tag.  I don’t want to speak for the 
> JOSM devs, but I doubt they would implement something like this either.
> ___
> 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] emergency=lifeguard

2018-06-10 Thread Bryan Housel
> Though I’m not fundamentally opposed to making it a hierarchical tag along 
> the lines of:
> emergency=lifeguard
> lifeguard=base/place/platform/tower

Sounds good - lets do it!  
What are the next steps?


> All the usual arguments for and against trying to change tags “by decree” 
> apply…

Be nice.  You can probably tell that I’m running an experiment today to see 
whether this tagging list is useful or not.
If I wanted to change a tag by decree, I’d just change it.


thanks, Bryan

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


[Tagging] I can't support transit:lanes

2018-06-10 Thread Bryan Housel
I’ve had a few recent conversations about this proposal:
 https://wiki.openstreetmap.org/wiki/Proposed_features/transit 


Unfortunately I can’t support it.

Not only is the name bad (it should be named `transition:lanes` but whatever), 
the bigger problem is that, as proposed, the tag can be placed on either a way 
or a relation.

The problem with tagging these on ways is that if you split the way, the tag 
breaks.  

No other tag works this way (except maybe for address interpolation lines, but 
presumably anybody splitting one of those would know that they need to adjust 
the numbers on the endpoints).  

I’m not going to add a special rule in iD to warn people if they are splitting 
a way with a lane transition tag.  I don’t want to speak for the JOSM devs, but 
I doubt they would implement something like this either.

The only way I’ll be able to support lane transitions would be as a relation 
that has similar semantics to turn restrictions.. from/via/to.  Keep it simple 
(no multi via ways please).  This is already an understood way of tagging 
things that connect 2 ways.  (could you imagine if we tagged turn restrictions 
as  maybe-a-relation or maybe-a-way-tag ?? nope!)

I notice that `transit:lanes` has already been tagged on around 4000 or so 
ways, so I thought it would be worth pointing out that the proposal is Dead on 
Arrival in it’s current state.  We should rework it before people tag too many 
more of these and end up disappointed.

thanks, Bryan

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


[Tagging] emergency=fire_alarm_box

2018-06-10 Thread Bryan Housel
I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency 
 today.

Someone just made this page for emergency=fire_alarm_box a few weeks ago
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_alarm_box 


It seems like a good idea.  Should it be a thing?

Thanks , Bryan


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


[Tagging] emergency=lifeguard

2018-06-10 Thread Bryan Housel
I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency 
 today.

We have too many tags for different kinds of lifeguards.  This is too confusing.
I don’t want to have to show all these choices to iD users.

tag uses
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_base 
 202
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_place 
   39
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_platform 
 24
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_tower 
   424
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dwater_rescue_station 
 197


More details here:
https://github.com/openstreetmap/iD/issues/4918#issuecomment-374611561 



Let’s just use one tag `emergency=lifeguard`
We can change this before the tags gain too much more traction (a few hundred 
uses is not very many)

If people really want to map whatever the lifeguard sits on, they can use a 
different tag for that.
`lifeguard_type=platform`  or `tower` or something.


Thanks, Bryan

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


[Tagging] emergency=first_aid_kit

2018-06-10 Thread Bryan Housel
I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency 
 today.

Can we add a tag for `emergency=first_aid_kit` ?

thanks, Bryan

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


Re: [Tagging] The endless debate about "landcover" as a top-level tag

2018-06-06 Thread Bryan Housel
This comes up for discussion on iD’s issue tracker sometimes, and I always 
close it as something we won’t change.
The usage numbers just don’t support it.  

https://github.com/openstreetmap/iD/issues/4272 

https://github.com/openstreetmap/iD/issues/4824 


There are several millions of existing objects in the database tagged a certain 
way. Many were imported this way or added years ago, so I don’t think it is 
fair to blame editor presets for the current situation.

Unless someone wants to review them, or the community changes their stance on 
mechanical editing, these tags are the ones we’re stuck with, even if the 
English word does not perfectly describe how the tag is used.

thanks, Bryan



> On Jun 6, 2018, at 10:22 AM, Jeroen Hoek  wrote:
> 
> On 06-06-18 16:13, Mateusz Konieczny wrote:
>> For start - is there a well written proposal?
>> Is there a JOSM preset that people can manually enable?
>> Is there a well written issue proposing support in JOSM, iD, Vespucci (if 
>> already
> 
> Good points.
> 
> Perhaps I'll give it a go to write a concept for such a proposal. In addition 
> to the landcover-proposal, the openstreetmap-carto issue on GirHub, and this 
> email-thread, are there any other proposals and resources I should look at?
> 
> ___
> 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] tagging of one-way cycle lanes

2018-05-13 Thread Bryan Housel
Hah speaking of lanes..
Why does the osm wiki page for `leisure=track` list `lanes=*` under the “useful 
combination” section.
https://wiki.openstreetmap.org/wiki/Tag:leisure=track 


I don’t believe I’ve ever seen an athletics track that allowed motorized 
vehicles to drive around it.

It kind of makes one question whether a community edited wiki is a good way to 
standardize a tagging scheme intended to produce a coherant mapping dataset.  
Bold suggestion: maybe the people who write the tools should just get together 
over beers and decide what all the tags should be.  I’ll buy!

Until then, I think it would be great if people are nicer to one another, 
respect each other’s viewpoints, be willing to be wrong, and don't take either 
the established tagging or the wiki too seriously.  Everything in OSM is broken 
to some degree, but everything in OSM can be improved if people care enough to 
do so.

Thanks, Bryan

p.s. Yes iD does suggest the lanes tag on athletic tracks based on this wiki 
page.  Don’t hate me.
p.p.s.  It’s been this way at least 4 years and nobody has complained.



> On May 13, 2018, at 4:32 PM, Mateusz Konieczny  
> wrote:
> 
> 13. May 2018 20:58 by ba...@ursamundi.org :
> 
> On Sun, May 13, 2018 at 1:36 PM, Johnparis  > wrote:
> Back to this again, Paul. It is getting tiresome. If you don't like how the 
> tag is defined, create a new one. Don't vandalize the old one.
> 
> Improvement=vandalism.  Got it.
> 
> 
> There is a clear consensus that redefining lanes tag is not considered to be 
> an improvement.
> 
> ___
> 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] service:vehicle: prefix

2018-05-06 Thread Bryan Housel
Hey all, this is something I added to iD because we can’t support reusing the 
`service=*` tag to also store values for vehicle services.  The tag is already 
overwhelmingly used to hold values for `highway=service` and `railway=service`.

So we added `service:vehicle` for users to tag these, and it follows what 
`service:bicycle:*` does.

For more details see:
https://github.com/openstreetmap/iD/issues/5008 

https://github.com/openstreetmap/iD/issues/4497 

https://github.com/openstreetmap/iD/issues/3535 


Please update the wiki, thanks!
Bryan



> On May 6, 2018, at 12:35 AM, Warin <61sundow...@gmail.com> wrote:
> 
> So ... no documentation. Nor discussion visible on the wiki. 
> 
> But follows the practice of service:bicycle:repair=yes which is poorly 
> documented on 
> https://wiki.openstreetmap.org/wiki/Key:service:bicycle:repair 
> 
> 
> 
> 
> On 06/05/18 13:42, Graeme Fitzpatrick wrote:
>> As part of shop=car_repair
>> 
>> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar_repair 
>> 
>> 
>> Thanks
>> 
>> Graeme
>> 
>> On 6 May 2018 at 09:51, Thilo Haug OSM > 
>> wrote:
>> Hi all,
>> 
>> what is the service:vehicle: prefix good for,
>> and where is it documented ? (1 223 occurrences)
>> 
>> https://taginfo.openstreetmap.org/keys/service%3Avehicle%3Acar_repair#overview
>>  
>> 
>> 
>> Cheers.
>> Thilo
>> 
>> 
>> 
>> ___
>> 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 mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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


[Tagging] iD news - v2.8.0, GSoC, OSM-US Hackathon 5/21-5/22 at Mapbox DC!

2018-05-04 Thread Bryan Housel
Hello all!  I’ve got a bunch of exciting items to share about iD - please check 
out the news and share..


  iD 2.8.0 released, including Community Index 
We've changed how things look on the post-upload screen. Now after saving your 
edits, you will see a list of OpenStreetMap communities that are active around 
the area where you are editing.  Reach out to nearby mappers and say hello!

If your local community group or meetup is missing, please open an issue or 
pull request here: 
https://github.com/osmlab/osm-community-index/ 


Changelog:
v2.8.0 changelog:  
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#280 


Twitter:
v2.8.0 announcement, community index: 
https://twitter.com/bhousel/status/985981732737314818 




  Google Summer of Code!
OpenStreetMap is again participating in Google Summer of Code, and we have 2 
projects to improve iD.  Welcome Princi and Thomas!

•  Princi Vershwal (mentored by Sajjad Anwar) will be adding support for 
viewing vector tiled data:
   https://www.openstreetmap.org/user/Princi%20Vershwal/diary/43802 


•  Thomas Hervey (mentored by Marc Farra) will be adding support for OSM Notes:
   https://www.openstreetmap.org/user/Thomas_Hervey/diary/43795 


Twitter:
iD GSoC announcement:  https://twitter.com/bhousel/status/990337518754238469 




‍  OSM US Spring Hackathon - 5/21-5/22 at Mapbox DC
Join us May 21-22 in Washington, DC at the Mapbox office for a 2 day OSM 
hackathon!  
Stop by between 9am-6pm and work with us, followed by an evening social event. 

This is the perfect opportunity to meet up with other developers, designers, 
and mappers in the OSM community and build something awesome. It could be a new 
feature for an open source project, a fun map style, a documentation or 
translation improvement, or something completely random.
 
Bring your laptops and your ideas. All are welcome!

Details and RSVP HERE:  https://osmhacks.splashthat.com/ 


Looking for ideas? Check out :
OSM Top 10 Tasks:  https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks 

osmlab/osm-planning: https://github.com/osmlab/osm-planning 


Twitter:
OSM US Spring Hackathon:  
https://twitter.com/OpenStreetMapUS/status/987502081866190849 




Follow and star the iD project on GitHub to show your support:  
https://github.com/openstreetmap/iD 
And follow me on Twitter https://twitter.com/bhousel 
 for the latest iD news. 

Thank you!
❤️ Bryan, and the rest of the  team.

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


Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

2018-04-06 Thread Bryan Housel
Hey tagging@
Wearing my “maintainer of iD” hat today, I feel like it’s important to comment 
on this.

I agree it would be great to be able to build a dataset of legal defaults which 
can be used by routers and editors in interesting ways.  This is a thing that 
comes up for discussion frequently.  I commented here: 
https://github.com/osmlab/osm-planning/issues/5#issuecomment-371471072 
  about 
the possibility of building a special index for these things.  We could use 
this for defaults for turn restrictions, max speed, etc.

However..
Any solution for encoding defaults should not depend on fully downloading 
relations to work.  

Just as a test, I fully downloaded the boundary of Germany
https://api.openstreetmap.org/api/0.6/relation/51477/full 

On my connection, that call downloads about 27MB of xml and takes about 58sec 
to run.

I think people do not realize how difficult it is for us who write software to 
work with huge relations.  I can’t just pause whatever the user is doing for a 
minute to download the boundary of Germany in order to decide whether the user 
is currently editing in a spot that allows u-turns or not.  

Even if I were to do the downloading in a background thread, it means that 
there are things a user can’t do for several minutes, as we background download 
information about whatever relations the user is inside of.  An editor like iD 
always has an incomplete picture of the world.  

So, some ideas that would work:
- precompute this information into an index that we bundle with iD (similar to 
our imagery and community indexes)
- fetch this info from a fast API (e.g. if local defaults were something 
Nominatim could return, that would be ok)


Thanks for listening!
Bryan





> On Apr 6, 2018, at 4:03 AM,  
>  wrote:
> 
> Yes, that's from 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Defaults which André 
> Pirard linked to just recently here.
> 
> Personally, I'm not a huge fan of the syntax. I would prefer the use of 
> sub-relations.
> 
> You would then have a type=defaults relation, with apply_to members that 
> specify the areas where the rules apply and match:(condition) members that 
> refer to type=default relations which can simply contain a set of plain 
> key=value tags (and don't need to have any members, they are just containers 
> for tags).
> 
> If the same bunch of default values applies to different things with 
> different matching rules, you can just refer to the same sub-relation 
> multiple times.
> 
> One issue with all this is that while you can encode a lot of useful 
> information this way, it doesn't help cases like the "it's not legal by 
> default to make u-turns at signal controlled intersections" in Queensland. As 
> such things can not be expressed with just a tag or two as default values on 
> existing objects. They require specific coded support in router engines.
> 
> For that I would suggest something like
> 
> rule:no_u_turn_at_signals=yes on the defaults relation, and the router 
> engines need to know what these mean then.
> 
> Cheers,
> Thorsten
> 
>> -Original Message-
>> From: Frederik Ramm 
>> Sent: Friday, 6 April 2018 16:39
>> To: tagging@openstreetmap.org
>> Subject: Re: [Tagging] no_u_turn restrictions for every entry/exit
>> into a roundabout when the way is split because of physical
>> separation?
>> 
>> Hi,
>> 
>> On 04/06/2018 05:26 AM, osm.tagg...@thorsten.engler.id.au wrote:
>>> Putting information about the legal default into OSM is not the
>> problem.
>>> It’s just that nobody has developed a schema for it yet.
>> 
>> The French have invented something: Check the "Part of..." listing
>> here
>> 
>> https://www.openstreetmap.org/relation/11980
>> 
>> It seems that a couple more of these exist, e.g.
>> 
>> https://www.openstreetmap.org/relation/1124248
>> 
>> I don't know if anyone actually uses them.
>> 
>> 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
> 
> 
> 
> ___
> 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] Rubberised playground surface

2018-03-12 Thread Bryan Housel
Yes, it is typical for the long tail of tag values to be misspellings or 
variations in capitalization or dashes vs. underscores.
For each of these, there are fewer than 10 values worldwide - not really 
alarming.  I think people clean them up sometimes.

Anyway, you find all kinds of interesting stuff on taginfo :)

Thanks, Bryan



> On Mar 12, 2018, at 9:17 AM, Andy Mabbett <a...@pigsonthewing.org.uk> wrote:
> 
> "On 12 March 2018 at 13:02, Bryan Housel <br...@7thposition.com> wrote:
>> Searching https://taginfo.openstreetmap.org/keys/surface#values for “rubber”
>> turns up a few alternatives
> 
>> rubber 258
>> rubbercrumb 170
>> Rubber 7
>> rubberized 6
>> recycled_rubber 6
>> rubber_mulch 4
>> rubber_crumb 3
>> rubber_grass 3
> 
> Whatever the correct value turns out to be, there's an alarming level
> of redundancy there.
> 
> "Rubber" and "recycled_rubber" should both be "rubber".
> 
> "rubbercrumb" and "rubber_crumb" are clearly the same concept.
> 
> I wonder if this is typical across most of our tag values?
> 
> -- 
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
> 
> ___
> 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] Rubberised playground surface

2018-03-12 Thread Bryan Housel
Searching https://taginfo.openstreetmap.org/keys/surface#values 
 for “rubber”
turns up a few alternatives, with “rubbercrumb” having the most traction:

rubber  258
rubbercrumb 170
Rubber  7
rubberized  6
recycled_rubber 6
rubber_mulch4
rubber_crumb3
rubber_grass3




> On Mar 12, 2018, at 8:03 AM, Andy Mabbett  wrote:
> 
> Suggestions, please, for tagging the surface underneath playground
> items like swings and slides, which is made of a soft, rubber-like
> material.
> 
> I've used surface=rubber, for now, but that's not really accurate.
> 
> -- 
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
> 
> ___
> 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] iD news - v2.7.0, new imagery, upgraded turn restriction editor

2018-03-05 Thread Bryan Housel
Hey everyone, I just released iD v2.7.0 and it’s now available for editing on 
openstreetmap.org 

 Release Highlights

•  We've added support for more background imagery from WMS servers. 
Thanks Martin Raifer and Guillaume Rischard for your work on this..
Press B to open the Background pane and see if new imagery is available in your 
area.

• ↪️ The turn restriction editor just got a big update!
• Include nearby connected roads (with configurable distance)
• Hover over a from way to see which paths are restricted or allowed
• Add restrictions that span one or more via ways (e.g. divided highway 
u-turns)
• Add `only_` turn restrictions (e.g. only straight on)
• View popup help for more information about working with turn 
restrictions
Try selecting a junction node in a complex intersection, editing turn 
restrictions, and viewing the popup help.

And as always, many more presets, bugfixes, and performance improvements.


Developers, we need your help!
We’re starting to add Flow annotations to iD’s source code.  Flow is a 
type-checking system to help catch common errors in JavaScript code (an untyped 
language).  If you’re interested in learning about the iD internals or want to 
learn Flow, please help out!  This is a great task for anyone, from beginners 
to experts.  Check out this GitHub issue for more info:
https://github.com/openstreetmap/iD/issues/3744#issuecomment-370300570 



Changelog:
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#270 


Twitter:
v2.7.0, turn restrictions:   
https://twitter.com/bhousel/status/970668042966523904 

Request for help, Flow annotations:  
https://twitter.com/bhousel/status/970505437526286336 


Reddit:
https://www.reddit.com/r/openstreetmap/comments/829591/id_editor_v270_released_and_available_on/
 



Follow and star the iD project on GitHub to show your support:  
https://github.com/openstreetmap/iD 
And follow me on Twitter https://twitter.com/bhousel 
 for the latest iD news. 

Thank you!
❤️ Bryan, and the rest of the  team.

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


Re: [Tagging] iD news - v2.6.0 lots of new features...

2018-01-22 Thread Bryan Housel
I can’t think of any reason off the top of my head, but anything is possible.. 
Please open an issue here, thanks!:  https://github.com/openstreetmap/iD/issues 
<https://github.com/openstreetmap/iD/issues>
Bryan



> On Jan 22, 2018, at 4:06 PM, Graeme Fitzpatrick <graemefi...@gmail.com> wrote:
> 
> 
> 
> 
> On 23 January 2018 at 02:48, Bryan Housel <br...@7thposition.com 
> <mailto:br...@7thposition.com>> wrote:
> Happy 2018!  I just released iD v2.6.0 yesterday..
> 
> Thank you & your team for all your hard work - some of these, especially the 
> brightness control will be very handy!
> 
> One question though - could this update have stopped Ctrl-S from opening the 
> normal "Save" page?
> 
> Did some mapping yesterday & when I hit Ctrl-S, it tries to save file 
> "OpenStreetMap" to "My Documents", as a "Web Page, Complete"?
> 
> Using Windows 8.1 via Chrome if this makes any difference? 
> ___
> 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] iD news - v2.6.0 lots of new features...

2018-01-22 Thread Bryan Housel
Happy 2018!  I just released iD v2.6.0 yesterday..


  Release Highlights

-   You can now adjust imagery brightness, contrast, saturation, and 
sharpness. 
(Not currently available in Internet Explorer or Edge)
Try enhancing the background imagery by opening the Background pane (shortcut 
“B") and adjusting the slider controls.

-   iD will now prevent users from drawing many self-crossing lines and areas. 
See issue https://github.com/openstreetmap/iD/issues/4646 
 for examples and more info. 
You can override these checks by holding down the Alt/Option key while drawing.

- ↕️  Features with a direction-type tag will display view cones indicating the 
directions they face. 
This is useful for mapping features like street signs, traffic signals, 
billboards, security cameras, and more.

-   Transit-related presets have been updated to support Public Transport v2 
tagging schema. 
Many presets have new icons too, to better match the mode of transport (tram, 
light rail, trolleybus, etc.)
Try mapping some transit platforms, stations, stop positions, etc.

-   We've completely refreshed the in-app Help content in iD. 
Huge thanks to Manfred Brandl, Minh Nguyễn, and our many volunteers on 
Transifex for their work on this!
Check out the new help texts by opening the Help pane (shortcut "H").


There are many many more presets, usability improvements, and bug fixes 
included too.
I’m really proud of the work we’ve been able to roll into this release, and I 
hope everyone takes a look at the changelog.
About 20 people contributed pull requests, many of them are first time 
contributors:  Thank you!  


Changelog:
   https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#260 


Twitter:
   v2.6.0, Imagery sliders:  
https://twitter.com/bhousel/status/955146596211150852 

   New Help content:  https://twitter.com/bhousel/status/955148340857065472 


Reddit:
   
https://www.reddit.com/r/openstreetmap/comments/7s2m3g/id_editor_v260_released_and_available_on/
 



As always, follow me on Twitter https://twitter.com/bhousel 
 for the latest iD news.  2018 will be a great 
year!

Thank you!
❤️ Bryan, and the rest of the  team.

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


[Tagging] iD news: v2.5.0, OpenStreetCam, and request for translation help..

2017-12-07 Thread Bryan Housel
Happy December!  We have lots moving in the iD editor project.  

  OpenStreetCam

Last month, I released iD v2.5.0 (November 10, 2017), which includes support 
for OpenStreetCam.  If you haven’t tried it yet, you should really check out 
how easy it is to work with street level imagery in iD.  

Read more here:
https://blog.mapbox.com/openstreetcam-support-for-the-id-editor-12934de61fa 


Please share:
https://twitter.com/Mapbox/status/931288819277578240 

https://twitter.com/bhousel/status/929116316614692864 



‍ New Help text coming soon

I recently merged a big pull request to iD, contributed by Manfred Brandl, to 
overhaul the internal help texts.  The good news is that it replaces those 
giant blocks of markdown text with short headings and texts which will be much 
easier to translate and maintain going forward.  The bad news is that it means 
all of that old help text needs to be translated again…

If you can translate, I need your help!

You don’t need to be a programmer - if you speak another language in addition 
to English, you can do this!  Please log into the iD project on Transifex, 
https://www.transifex.com/openstreetmap/id-editor/dashboard/ 
 and check the 
languages that are available for translation.  And share this info with 
*anyone* who you know that might want to get involved!  

Please share:
https://twitter.com/bhousel/status/933778248105910272 



As always, follow me on Twitter https://twitter.com/bhousel 
 for the latest iD news.  More great features 
coming soon...

Thank you!
❤️ Bryan, and the rest of the  team.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to map a bin with dog excrement bags dispenser

2017-10-10 Thread Bryan Housel
2 nodes, please!
It makes things much easier for iD, or any other data consumer that needs to 
match features to tag presets.
related thread on iD:  
https://github.com/openstreetmap/iD/issues/4191#issuecomment-318943309 


Thanks! Bryan


> On Oct 10, 2017, at 9:42 AM, Alejandro Moreno  wrote:
> 
> Hi,
> 
> In Spain it is common to find litter bins that have attached a dog excrement 
> bags dispenser. In Talk-es discussed how to map these bins 
> [https://lists.openstreetmap.org/pipermail/talk-es/2016-July/014171.html 
> ] 
> and we did not reach a conclusion.
> 
> There are 2 opinions:
> - 1 node with tags
> amenity = waste_basket
> vending = excrement_bags
> fee = no
> 
> - 2 nodes
> 1º
> amenity = vending_machine
> vending = excrement_bags
> payment: none = yes
> 
> 2º node (a few centimeters from the previous one):
> 
> amenity = waste_basket
> 
> What would be the most correct option?
> 
> ___
> 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] Feature Proposal - RFC - Public Transport v2 Vehicle Type "coach"

2017-10-07 Thread Bryan Housel
Hey, just want to add some thoughts here..

It would be really great if people could just use a tag for one thing.  Reusing 
a tag like `service=*` for multiple things makes it difficult for us to suggest 
good values in the iD editor based on tag usage.

Check out the popular values for the service tag:  
https://taginfo.openstreetmap.org/keys/service#values 


You can see that it’s mostly highway stuff, with some railway and other things 
mixed in.

Because of this, we need to maintain different lists in iD for “service=* 
values for highways” and “service=* values for railways”.  This is ok, but the 
disadvantage is that it is more lists that we need to maintain in the editor, 
and it kind of steers people away from being able to use any tag values that 
they like.

Since the service tag only has 1352 of these kind of new “bus route" uses, it 
would be really great to retag these using a namespaced key like 
`route:service` before it gains too much traction.

Inventing tags is totally fine - but reusing existing ones for new uses can be 
problematic... I hope this is helpful information for people to know why 
namespacing keys is helpful, and why certain things are difficult to support in 
iD..


Thanks!
Bryan





> On Oct 6, 2017, at 7:22 AM, Martin Koppenhoefer  
> wrote:
> 
> 2017-10-06 13:00 GMT+02:00 Michael Reichert  >:
> Some people (including myself) started using service=* for train routes
> about two to three years ago. The service=* tag was part of the Oxomoa
> Schema. Why not using this tag with different values for bus routes?
> 
> 
> by looking at the tags in use on bus route relations, I have found there are 
> already people using this tag:
> 
> https://taginfo.openstreetmap.org/tags/route=bus#combinations 
> these are the 
> current numbers:
> 
> service 1352
> 
> bus 3039
> 
> Cheers,
> Martin
> ___
> 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] Mapping hotels on buildings or areas around buildings

2017-09-29 Thread Bryan Housel
Be careful what you wish for!  Here is a list of around 370 other feature types 
that you will change the meaning of, if areas are always assumed to be property 
outlines and not building outlines. 

https://github.com/openstreetmap/iD/search?utf8=%E2%9C%93=building_area= 
<https://github.com/openstreetmap/iD/search?utf8=%E2%9C%93=building_area=>

That’s a lot of cleanup challenges...

AFAIK (from memory) the notable exceptions are schools/universities, hospitals, 
gas stations, and power substations.

(Just to make sure we’re scoping the discussion properly, this is for POI kinds 
of features, not stuff like `landuse=*` or `natural=*`)




> On Sep 29, 2017, at 11:02 AM, Martin Koppenhoefer <dieterdre...@gmail.com> 
> wrote:
> 
> 
> sent from a phone
> 
>> On 29. Sep 2017, at 16:50, Bryan Housel <br...@7thposition.com> wrote:
>> 
>> So if we collectively decide to change `tourism=*` tags to be property 
>> outlines (like hospitals and schools), 
> 
> 
> +1, I’d see it like this for all “functions”, regardless of the key (amenity, 
> man_made, tourism, shop, historic, etc.)
> 
> 
> cheers,
> Martin 
> ___
> 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] Mapping hotels on buildings or areas around buildings

2017-09-29 Thread Bryan Housel
If you draw a “Hotel” in iD, you’ll see that it gets a `building=yes` tag added 
to it.  
(Users can change this if they like).

Again, this is exactly in agreement with what the osm wiki page for 
`tourism=hotel` says to do.




> On Sep 29, 2017, at 11:06 AM, LeTopographeFou  
> wrote:
> 
> 
>> This is how iD interprets the tag - as a building outline.  
> 
> I disagree, when you look for "Hotel" iD proposes both "Hotel" (in gray which 
> means it is an area in the iD codes) and "Building Hotel" (in red and with a 
> building picture which both means it is a building). Same for Hospitals. For 
> me iD is already ready.
> 
> But one may propose a new translation to replace "Hotel" by "Hotel Grounds" 
> to be consistent with how hospitals are proposed in iD.
> 
> By the way this is how I tag hotels now so +1 with the proposal.
> Yours,
> LeTopographeFou

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


Re: [Tagging] Mapping hotels on buildings or areas around buildings

2017-09-29 Thread Bryan Housel
Yes, but the https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dhotel 
 page says
"Set a node  or draw as an area 
 along the building outline."

This is how iD interprets the tag - as a building outline.  

So if we collectively decide to change `tourism=*` tags to be property outlines 
(like hospitals and schools), 

I hope:
- somebody opens an issue on iD to let me know to change the wording of the 
preset.
- somebody creates a challenge to cleanup the existing data that is not tagged 
this way.
- somebody fixes the wiki (well somebody should do this anyway as it currently 
says 2 different things)


Thanks, Bryan



> On Sep 29, 2017, at 10:32 AM, Michal Fabík  wrote:
> 
> On Fri, Sep 29, 2017 at 4:21 PM, Janko Mihelić  wrote:
>> Hi,
>> 
>> should only the hotel buildings be tagged with tourism=hotel or the whole
>> area that is owned by the hotel?
>> 
>> I think if the hotel doesn't have more than one building, and if the hotel
>> grounds are not very big, or if they are accessible by public, only the
>> building gets tagged. But if there are more buildings, outside pool and/or
>> parks accesible only by guests, we might consider tagging an area around
>> those buildings.
>> 
>> Does this thinking align with most mappers?
> 
> Hi,
> I don't recall the last time I tagged a hotel but that's how I would
> to it. Actually, the wiki page for buildings confirms this:
> building=hotel: "A building designed with separate rooms available for
> overnight accommodation. Normally used in conjunction with
> tourism=hotel for the hotel grounds including recreation areas and
> parking." (https://wiki.openstreetmap.org/wiki/Key:building#Values)
> 
> Regards,
> 
> -- 
> Michal Fabík
> 
> ___
> 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] iD news: v2.4.0 released

2017-08-26 Thread Bryan Housel
Oh thanks for the correction, I did copy paste that too quickly..
The tags are: 
`ideditor:walkthrough_started`
`ideditor:walkthrough_progress`
`ideditor:walkthrough_completed`


> On Aug 26, 2017, at 7:53 AM, marc marc <marc_marc_...@hotmail.com> wrote:
> 
> Thanks.
> 
> Le 26. 08. 17 à 07:47, Bryan Housel a écrit :
>> `ideditor:walkthrough_started=yes`  (“yes” if the user started the 
>> walkthrough)
>> `ideditor:walkthrough_started=yes`  (“yes” if the user completed all 
>> walkthrough sections)
> 
> both have the same tag name and value :)
> ___
> 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] iD news: v2.4.0 released

2017-08-25 Thread Bryan Housel
iD v2.4.0 was released August 25, 2017 and is now available for editing on 
openstreetmap.org 

  A few highlights from the release:

NEW Esri World Imagery layer:
Esri has made their World Imagery Service available for OSM use! 
Read more here:  
https://blogs.esri.com/esri/arcgis/2017/08/24/world-imagery-in-osm/ 


NEW fields on the save screen:
   • Added a checkbox for mappers to request for someone to review their edits.
   • Added a Source field to allow users to add multiple sources.
   • Added a Hashtags field to allow users to add multiple event hashtags.
- Hashtags can also be set via the API from a Task Manager or Q/A app.  
- Hashtags are automatically extracted from the `comment` field.

NEW changeset tags for improved changeset analysis
   • `review_requested=yes`  (“yes” if the user has checked the box)
   • `source=*`  (semicolon delimited, e.g. “survey;gps")
   • `hashtags=*`  (semicolon delimited, e.g. “#MissingMaps;#Tanzania”)
   • `changesets_count=*`  (number of edits the user has made, will be “0” for 
someone making their first edit)

  Walkthrough tags, will be set only if a user has made <100 edits:
   • `ideditor:walkthrough_started=yes`  (“yes” if the user started the 
walkthrough)
   • `ideditor:walkthrough_progress=*`  (semicolon delimited, e.g. 
"welcome;navigation;point;area”)
   • `ideditor:walkthrough_started=yes`  (“yes” if the user completed all 
walkthrough sections)

Performance:
   • iD can now schedule deferred work in modern browsers with 
requestIdleCallback, (contributed by Kushan Joshi).  
This means big speedups in parsing, loading data from OSM, and rendering.

Presets:
   • Added presets for many theme park attractions (contributed by Willie 
Marcel)
   • Added preset for `amenity=shower` (contributed by JamesKingdom)
   • Added preset `emergency=life_ring` (contributed by JamesKingdom)
   • Added presets and icons for railway mapping Buffer Stop, Derailer, 
Milestone, Signal, Switch, Train Wash (contributed by JamesKingdom)

...and more!


Changelog:
   https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#240 


Twitter:
   v2.4.0 + new save screen:  
https://twitter.com/bhousel/status/901280750540132352 

   Esri World Imagery announcement: 
https://twitter.com/geogangster/status/901194478622433280 


Follow me on Twitter https://twitter.com/bhousel  
for more iD news and sneak peaks.


Thanks! 
Bryan___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rivers classification

2017-08-08 Thread Bryan Housel
“official_length" is actually a good example of something that really does not 
need to be tagged in OSM, and could instead be looked up if the river has a 
wikidata tag.   See https://www.wikidata.org/wiki/Q3392 
  for others.

Bryan




> On Aug 8, 2017, at 10:01 AM, Richard  wrote:
> 
> On Tue, Aug 08, 2017 at 03:20:31PM +0200, Daniel Koć wrote:
>> W dniu 08.08.2017 o 12:07, Daniel Koć pisze:
>>> I've just found that length=* tag is quite closely connected to waterways
>>> (almost 72% uses):
>>> 
>>> https://taginfo.openstreetmap.org/keys/length#combinations
>>> 
>>> Taginfo does not show such combination with rivers (it probably omits
>>> anything <1000 uses), but it's 446 lines already:
>>> 
>>> http://overpass-turbo.eu/s/qS7
>> 
>> Looks like a "distance" tag is better than "length" when it comes to long
>> objects like rivers, so I would recommend it in waterway Wiki pages instead.
>> We have 915 such uses with waterways:
> 
> I know that you want save some computing power but nothing should be easier 
> to compute than the length so encouraging mappers to add their own estimates 
> doesn't seem like the best idea. The 915 uses possibly have a special purpose?
> 
> However if there is something like "official_length" of a river (for example
> mentioned in wikipedia) that could be certainly tagged.
> 
> Other tags that might help are those relating to ships.
> 
> Richard
> 
> ___
> 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] toilets:wheelchair or wheelchair_toilet (Both iD presets)

2017-05-15 Thread Bryan Housel
I think I’d rather see people just use the existing wheelchair key, which iD 
provides in the “Add Field” dropdown.
https://wiki.openstreetmap.org/wiki/Key:wheelchair 
<https://wiki.openstreetmap.org/wiki/Key:wheelchair>

The fields that we expose for restaurants and other buildings are already 
really cluttered with other things.  

I don’t think I would be able to explain to new mappers that they are supposed 
to use the `wheelchair` tag on anything, but the `toilets:wheelchair` tag on a 
building that has the toilets in it, unless they want to map the toilets 
individually within the building as point nodes.  Too complicated.

Bryan



> On May 15, 2017, at 8:01 AM, Dave F <davefoxfa...@btinternet.com> wrote:
> 
> Ah, I was unaware of the 'Add fields' & 'All tags' differences. Does iD pull 
> in all taginfo or is there a minimum number limit?
> 
> As Wheelmap only displays a subset of all establishments people adding data 
> are using iD. Would it big a big problem if 'toilets:wheelchair' & 
> wheelchair:description were added to the defaults.
> 
> DaveF.
> 
> 
> 
> On 14/05/2017 17:00, Clifford Snow wrote:
>> It looks like iD is pulling in data from taginfo when manually adding a tag. 
>> When searching for wheelchair, iD only offers a point object, which is 
>> correct. We don't tag wheelchairs, we tag objects that have wheelchair 
>> attributes. 
>> 
>> Clifford
>> 
>> On Sun, May 14, 2017 at 9:15 AM, Dave F <davefoxfa...@btinternet.com 
>> <mailto:davefoxfa...@btinternet.com>> wrote:
>> https://pbs.twimg.com/media/C_y-XYuXYAEbFAH.jpg 
>> <https://pbs.twimg.com/media/C_y-XYuXYAEbFAH.jpg>
>> 
>> 
>> 
>> DaveF
>> 
>> 
>> 
>> On 14/05/2017 16:04, Bryan Housel wrote:
>>> I just searched the iD code and none of these tags are iD presets.
>>> Thanks, Bryan
>>> 
>>> 
>>> 
>>>> On May 14, 2017, at 9:41 AM, Dave F <davefoxfa...@btinternet.com> 
>>>> <mailto:davefoxfa...@btinternet.com> wrote:
>>>> 
>>>> Hi
>>>> 
>>>> toilets:wheelchair 64875 (iD & wheelmap preset)
>>>> wheelchair_toilet 4550 (iD preset)
>>>> 
>>>> What does wheelchair_toilet represent that's different from 
>>>> toilets:wheelchair?
>>>> If there isn't one I think wheelchair_toilet should be removed from iD's 
>>>> presets
>>>> 
>>>> Other combinations which should potentially be changed:
>>>> wheelchair:toilets 467
>>>> wheelchair:toilet 10
>>>> toilet:wheelchair 6
>>>> 
>>>> DaveF
>>>> 
>>>> ___
>>>> Tagging mailing list
>>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>>> https://lists.openstreetmap.org/listinfo/tagging 
>>>> <https://lists.openstreetmap.org/listinfo/tagging>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/tagging 
>>> <https://lists.openstreetmap.org/listinfo/tagging>
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging 
>> <https://lists.openstreetmap.org/listinfo/tagging>
>> 
>> 
>> 
>> 
>> -- 
>> @osm_seattle
>> osm_seattle.snowandsnow.us <http://osm_seattle.snowandsnow.us/>
>> OpenStreetMap: Maps with a human touch
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging 
>> <https://lists.openstreetmap.org/listinfo/tagging>
> 
> ___
> 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] toilets:wheelchair or wheelchair_toilet (Both iD presets)

2017-05-14 Thread Bryan Housel
I just searched the iD code and none of these tags are iD presets.
Thanks, Bryan



> On May 14, 2017, at 9:41 AM, Dave F  wrote:
> 
> Hi
> 
> toilets:wheelchair 64875 (iD & wheelmap preset)
> wheelchair_toilet 4550 (iD preset)
> 
> What does wheelchair_toilet represent that's different from 
> toilets:wheelchair?
> If there isn't one I think wheelchair_toilet should be removed from iD's 
> presets
> 
> Other combinations which should potentially be changed:
> wheelchair:toilets 467
> wheelchair:toilet 10
> toilet:wheelchair 6
> 
> DaveF
> 
> ___
> 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] iD news: v2.1.0 released

2017-02-04 Thread Bryan Housel
iD v2.1.0 was released Feb 4 2017 and is now available for editing on 
openstreetmap.org 

Here are some of our favorite new features:
- Disconnected endpoints now appear slightly larger, and iD will warn if a user 
creates a disconnected road
- Improved save flow directs users to enter their comment and upload their 
changes (some users would miss that step)
- RTL languages like Arabic and Hebrew are now drawn correctly along line paths 
(thanks Milad Karbasizadeh)
- Improved checks to avoid creation of duplicate consecutive nodes and invalid 
geometries (thanks slhh)
- Users must select vertices and nodes before dragging them, preventing 
accidental drags (thanks Eduard Popov)
- Now support KML and GeoJSON in addition to GPX files (thanks Mert Emin 
Kalender)
- Icons were refreshed to use the latest Maki iconset (thanks Ajith Ranka)
- Better country-specific customization of address fields (thanks Natsuyasumi)
- Reflect operations!  You can now reflect shapes with T ↔️ and Y ↕️  (thanks 
Psigio)

By my count, 17 people contributed to this release, which feels like a record 
high.  Thank you everyone for an awesome start to 2017!  

If you are interested in contributing, or just want to see what we are up to, 
please follow and star the iD project on GitHub 
https://github.com/openstreetmap/iD  


Changelog: 
   https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#210 


Twitter:  
  v2.1.0: https://twitter.com/bhousel/status/827875204546306049 

  New Icons: https://twitter.com/bhousel/status/827724917806346241 

  Follow me on Twitter https://twitter.com/bhousel 
 for more iD updates.


Thanks! 
Bryan

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


Re: [Tagging] name:zh-yue

2016-11-27 Thread Bryan Housel
> On Nov 27, 2016, at 5:28 AM, jc86035 <jc86...@openmailbox.org> wrote:
> 
> Should a separate bug be filed to fix iD before your fix to use CLDR is
> implemented,

No need to file a separate bug..



> and would it be a good idea to go through all of the
> objects using name:zh-yue=* (via overpass turbo) and replace the tag
> with name:yue=*?

Sounds like a good idea to me (and I wish there were more enthusiasm within OSM 
for cleaning up tags), but please check with the local community before doing a 
mass tag change like that.

Thanks, Bryan





> jc86035
> 
> Bryan Housel:
>> Worth mentioning here that iD might be doing the wrong thing:
>> https://github.com/openstreetmap/iD/issues/2457 
>> <https://github.com/openstreetmap/iD/issues/2457> 
>> <https://github.com/openstreetmap/iD/issues/2457 
>> <https://github.com/openstreetmap/iD/issues/2457>>
>> 
>> We are using wikimedia as our source for languages, which is where the 
>> "zh-yue" came from.
>> As mentioned in the ticket, I’m planning to switch this to a more proper 
>> language list.
>> CLDR has: 
>> https://github.com/unicode-cldr/cldr-core/blob/master/availableLocales.json 
>> <https://github.com/unicode-cldr/cldr-core/blob/master/availableLocales.json>
>>  
>> <https://github.com/unicode-cldr/cldr-core/blob/master/availableLocales.json 
>> <https://github.com/unicode-cldr/cldr-core/blob/master/availableLocales.json>>
>> 
>> So `name:zh` and `name:yue` are probably both valid language codes, and 
>> `name:zh-yue` probably is not.
>> 
>> Thanks,
>> Bryan
>> 
>> 
>> 
>> 
>>> On Nov 24, 2016, at 8:53 AM, jc86035 <jc86...@openmailbox.org> wrote:
>>> 
>>> Mostly in Hong Kong, some places with Cantonese names use name:yue=*,
>>> whereas others use name:zh-yue=* (which is supported by iD). Should
>>> those objects using the former be changed to use the latter? (In
>>> addition, should those objects with name:zh-yue=* same as name:zh=* have
>>> name:zh-yue=* deleted?)
>>> 
>>> jc86035
>>> 
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>> 
>> 
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging 
>> <https://lists.openstreetmap.org/listinfo/tagging>
>> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging 
> <https://lists.openstreetmap.org/listinfo/tagging>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] name:zh-yue

2016-11-24 Thread Bryan Housel
Worth mentioning here that iD might be doing the wrong thing:
https://github.com/openstreetmap/iD/issues/2457 


We are using wikimedia as our source for languages, which is where the "zh-yue" 
came from.
As mentioned in the ticket, I’m planning to switch this to a more proper 
language list.
CLDR has: 
https://github.com/unicode-cldr/cldr-core/blob/master/availableLocales.json 


So `name:zh` and `name:yue` are probably both valid language codes, and 
`name:zh-yue` probably is not.

Thanks,
Bryan




> On Nov 24, 2016, at 8:53 AM, jc86035  wrote:
> 
> Mostly in Hong Kong, some places with Cantonese names use name:yue=*,
> whereas others use name:zh-yue=* (which is supported by iD). Should
> those objects using the former be changed to use the latter? (In
> addition, should those objects with name:zh-yue=* same as name:zh=* have
> name:zh-yue=* deleted?)
> 
> jc86035
> 
> ___
> 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] Proper Tag for Not-a-Roundabout

2016-11-07 Thread Bryan Housel
Previous discussion: 
https://lists.openstreetmap.org/pipermail/tagging/2014-June/017805.html 


Some people suggested `junction=traffic_circle`
It’s used in taginfo a few times but pretty unofficial and rare.

Bryan



> On Nov 7, 2016, at 9:30 AM, Daniel Hofmann  wrote:
> 
> Over at OSRM we're not only doing Routing on OSM but also Guidance for users 
> once a suitable route is found. In order to make the user experience great 
> and the instructions pleasant to use we differentiate between
> 
> 1/ Roundabouts
> Think: "at the roundabout take the nth exit"
> 
> 2/ Roundabout Intersections
> These are roundabouts with up to four ways and turn angles which makes the 
> turns obvious.
> Think: "at the roundabout turn left"
> 
> 3/ Rotaries
> These are large and named roundabouts.
> Think: "at Meinplatz take the nth exit"
> 
> 4/ Not-a-Roundabout (what this post is about)
> There are situations where one of the entering road has right of way, which 
> disqualifies the scenario for being classified as a roundabout. The Wiki has 
> a section on these Not-a-Roundabouts:
> 
> http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout#Not_a_roundabout 
> 
> > In all these cases, the key “junction” is not necessary at all. You need no 
> > special tagging. 
> 
> Most of these Not-a-Roundabouts have a note on them, telling users not to tag 
> them as junction=roundabout as this is a common mistake. Here are two 
> examples in Berlin:
> 
> Bersarinplatz
> 
> http://www.openstreetmap.org/way/288767318#map=19/52.51849/13.45355=D 
> 
> 
> http://www.openstreetmap.org/directions?engine=osrm_car=52.51786%2C13.45348%3B52.51918%2C13.45281#map=19/52.51852/13.45327
>  
> 
> 
> Kottbusser Tor
> 
> http://www.openstreetmap.org/way/159155852#map=19/52.49898/13.41881=D 
> 
> 
> http://www.openstreetmap.org/directions?engine=osrm_car=52.49915%2C13.41952%3B52.49857%2C13.41852#map=19/52.49896/13.41865
>  
> 
> 
> As you can tell, for both of those situations the routing engine is not able 
> to issue special instructions since there is no tag to parse. And parsing 
> note tags for the occurrence of roundabout is not a solution ;)
> 
> With the current situations of having note="don't tag as roundabout" 
> pseudo-tags on most of those it would make sense to establish a proper 
> junction=not_a_roundabout tag (tag is up for discussion) software can parse 
> and make use of.
> 
> What's your opinion on Not-a-Roundabout?
> 
> Cheers,
> Daniel J H
> ___
> 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] iD v2.0.0 beta - help test!

2016-11-04 Thread Bryan Housel
We have been working really hard on iD the past few months and we’re releasing 
v2.0.0 in the next week or so.

iD v2.0.0 will look and feel the same as v1.x but has significant changes to 
the code structure. It is written in a modular style, and uses new tools to 
build the code.  This will benefit us by making it easier to keep iD's 
dependencies up to date, share iD code with other OSM projects, and keep 
current the with ever-changing state of the art in JavaScript development.

Huge thanks go out to to all of our contributors, the changelog is really 
amazing:
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#200 

(We are still adding a few more features and fixing bugs over the next week)


How you can help: 

1. Test the latest version of iD:
https://openstreetmap.us/iD/master/ 

2. Report any bugs that you find:
iD supports all modern operating systems and browsers.  When opening an issue, 
please include your operating system, browser type and version, and any 
information you can think of that might help us reproduce the issue.  
Screenshots are super helpful too!  
https://github.com/openstreetmap/iD/issues 


3. Translate! 
iD supports over 70 languages now, but most of them are not fully translated.  
We need your help!
Click below to open the iD translation project on Transifex.
https://www.transifex.com/ideditor/id-editor/ 


4. Spread the word:
The more help we get with testing the beta version, the better iD will be!
Twitter: https://twitter.com/bhousel/status/794666881563160576 


Thanks!  
Bryan

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


Re: [Tagging] Proposal for standardization of sidewalk schema (+ import)

2016-08-02 Thread Bryan Housel
Hey Meg,
I read through your proposal at 
http://wiki.openstreetmap.org/wiki/Proposed_features/sidewalk_schema 


I don’t see anything in there that is any different from how sidewalks and 
crossings are already being tagged in OSM.  This is good!

As far as I can tell, it doesn’t change any tags - it just establishes a 
preference for tagging sidewalks and crossings as separate features rather than 
including sidewalk tags on the related street geometry.

When sidewalks, curb ramps, and crossings are tagged as a separate features, it 
allows mappers to supply attributes essential for tagging situations like:
https://www.dropbox.com/s/ky4eolv1nm0805y/sidewalk.jpg?dl=0
…which can really ruin your day if you were to encounter that sidewalk in a 
wheelchair.

Thanks for your work in this area!  
Bryan




> On Aug 1, 2016, at 5:35 PM, Meg Drouhard  wrote:
> 
> Hello,
> 
> Our team is proposing a standardization of sidewalk tagging conventions in 
> OSM to simplify pedestrian network annotations and better represent the 
> physical reality of sidewalk ways.  This proposal is particularly concerned 
> with features of sidewalks that may aid or impede travel for people with 
> limited mobility.
> 
> Our schema proposal is available here: 
> http://wiki.openstreetmap.org/wiki/Proposed_features/sidewalk_schema 
> .
> 
> You can also read more about our project and group here: 
> www.opensidewalks.com .
> 
> Through the Imports list, we are also proposing to jump start sidewalk 
> annotation by importing open municipal data from the city of Seattle 
> (http://wiki.openstreetmap.org/wiki/Seattle,_Washington/Sidewalk_Import 
> ).
> 
> We appreciate any feedback you may have either through our discussion pages 
> or by email .
> 
> Thanks,
> 
> Meg Drouhard
> 
> ___
> 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] "no right turn on red" tagging?

2016-07-02 Thread Bryan Housel
Most tools follow the rule described here:
http://wiki.openstreetmap.org/wiki/Relation:restriction 


"If the first word is "no_", then no routing is possible from the "from" to the 
"to" member. If it is "only_", then you know that the only routing originating 
from the "from" member leads to the "to" member. This distinction is also shown 
in the examples section 
 of this 
page.”

So OSRM is correct in this case. 

If you want to make up a new restriction relation type, it’s better to use new 
tags.  
for example:
  type=restriction:on_red 
  restriction:on_red=no_right_turn


Thanks, Bryan




> On Jul 2, 2016, at 10:55 AM, Nathan Wessel  
> wrote:
> 
> Hi all,
> I've been running into some trouble with the following tag recently. 
> 
> 'restriction'='no_right_turn_on_red' 
>  
> mapped as a turn restriction relation. 
> 
> My problem is that OSRM treats it as a no_right_turn restriction, though 
> obviously it should not prevent all turning. The wiki indicates that this is 
> the expected behaviour though; it seems that anything beginning with 'no_' 
> means no turn is permitted from the 'from' way to the 'to' way. I brought 
> this up on the restriction talk page here 
>  
> and a couple people implied that this was definitely not the right tag, if 
> restriction is even the right key. I then brought the topic up for discussion 
> on talk-ca (about half of all occurrences of this tag are in Toronto and 
> Ottawa, where I'm having my particular routing issues), and the people on 
> that list were pretty adamant that the tag was useful and made sense as is. 
> One person suggested this should be reported as a bug 
>  for 
> OSRM. 
> 
> Who is right here? Should I report this as a bug and change the wiki to allow 
> turns on "^no_.*" relations as standard or should the tagging be changed? And 
> how?
> 

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


Re: [Tagging] Turn Lane Tagging?

2016-06-11 Thread Bryan Housel
My confusion was specifically about the use of `none` as part of a multiple 
lane indicator - like `none;left`or `none;right`.
`none` by itself is well documented and clear.

Thanks, Bryan



> On Jun 11, 2016, at 3:28 PM, Johan C  wrote:
> 
> In that case they also missed the examples on the same page :-)
> 
> Op 11 jun. 2016 20:04 schreef "Mike N"  >:
> On 6/11/2016 12:00 PM, Johan C wrote:
> I completely agree with Marc. Using none as a value in case no turn
> indication is present is valid, using || isn't. See the values of the
> turn:lanes key on this page:
> http://wiki.openstreetmap.org/wiki/Key:turn:lanes 
>  for reference.
> 
>   And I just realized that the editors may have interpreted the word 'none' 
> as nothing/blank (no text required).
> 
> 
> ___
> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Turn Lane Tagging?

2016-06-10 Thread Bryan Housel
Thanks James for the explanation, it does make sense now. I hope I wasn’t the 
only person confused to see that tag..  

I appreciate all the work that you’ve put into adding lane details OSM.  My 
goal is to make lane tagging easy for everyone.  

That said, I think you might be the only person in the world tagging turn lanes 
with `none;something`.  I checked taginfo and it seems like for value 
combinations like `left;none` there are around 5 in the world.  Yes, that count 
is off because Mapbox data team deleted some of yours and they shouldn’t have, 
and it’s great that they apologized, but still we are talking about something 
that looks kind of like an error and hasn’t been discussed anywhere that I can 
find.

For what it’s worth, I have also seen a few people suggest tagging like 
`width:lanes:start = 4|0`  `width:lanes:end = 4|4` (e.g. in meters) to describe 
the shape of that segment of road that widens into the turn lanes. Taginfo also 
suggests that this is used like 10 times in the whole world, and I also haven’t 
found it discussed anywhere.

Maybe this is a situation where the tagging list can discuss and come to 
consensus and do the whole wiki proposal voting thing?

We still have several months before the turn lane tagging will be available in 
iD, so there is plenty of time to work out these details.  In the worst case, 
we just won’t support it, and instead show a ‘?’ in the interface to indicate 
that there is some unrecognized tag in that lane and we will leave it alone.

Thanks, Bryan




> On Jun 10, 2016, at 10:16 PM, James Mast <rickmastfa...@hotmail.com> wrote:
> 
> I've been using the "turn:lanes:*=none;slight_right" & "slight_left;none" 
> tags to indicate which side a new lane has been added on a highway when going 
> from 1 to 2 lanes (sometimes "slight_left;slight_right" if the original lane 
> is centered between the two new lanes).  How else are people to properly 
> identify which side the new lane is being added to?  Take a look at this way 
> ( https://www.openstreetmap.org/way/419799887 
> <https://www.openstreetmap.org/way/419799887> ) and take a look at the Bing 
> imagery and look at the 'turn:lanes:forward' tag, and you'll see how this 
> can, and would be valid.  It's allowing the router to know that a new lane is 
> being added when combined with the next way 
> (https://www.openstreetmap.org/way/419799886 
> <https://www.openstreetmap.org/way/419799886> ) which has the 
> "lanes:forward=2" tag.  It also allows the routers to properly tell people to 
> get in the left lane if just ahead, there's a left turn they need to make.
> 
> From: Tod Fitch <t...@fitchdesign.com>
> Sent: Friday, June 10, 2016 9:45:56 PM
> To: Tag discussion, strategy and related tools
> Subject: Re: [Tagging] Turn Lane Tagging?
>  
> I haven’t seen “none;slight_right” as a value and am not sure how that should 
> look different than “slight_right” by itself. However “none” is a value 
> listed in the wiki [1] and I use it a lot as I find multiple vertical bars 
> hard to manually count/edit but I can see and count things like 
> “left|none|none” easier than “left||” when editing in JOSM.
> 
> [1] https://wiki.openstreetmap.org/wiki/Key:turn#Turning_indications 
> <https://wiki.openstreetmap.org/wiki/Key:turn#Turning_indications>
> 
> -Tod
> 
> 
>> On Jun 10, 2016, at 6:07 PM, Bryan Housel <br...@7thposition.com 
>> <mailto:br...@7thposition.com>> wrote:
>> 
>> Hey James,
>> 
>> (Disclaimer:  I work for Mapbox, but I am not part of the team that is doing 
>> the lane tagging, and can’t speak for them).
>> 
>> I do need to know more about your concern:   Is `none` as part of a multiple 
>> turn lane option documented anywhere? 
>> 
>> I’m asking because we are adding turn lane tagging to iD this summer [1], so 
>> I have been thinking a lot about turn lanes, and I have read through a lot 
>> of wiki pages and discussion pages, and this is the first I’ve seen anybody 
>> using a tag like `turn:lanes:backward=none;slight_right`.
>> 
>> It’s really important to me that I get this as correct as possible, because 
>> I can’t have iD overwriting somebody’s valid lane tagging.  I’d like to be 
>> able to show visually what a tag like `none;slight_right` means on the 
>> ground.
>> 
>> Thanks, Bryan
>> 
>> 
>> [1] https://www.mapbox.com/blog/osm-gsoc-id/ 
>> <https://www.mapbox.com/blog/osm-gsoc-id/>
>> 
>> 
>> 
>> 
>>> On Jun 10, 2016, at 7:45 PM, James Mast <rickmastfa...@hotmail.com 
>>> <mailto:rickmastfa...@hotmail.com>> wrote:
>>> 
>>> I honestly think Mapbox needs to stop imme

  1   2   >