Re: [Tagging] Designated spots for dogs to wait

[Anton Klim]

TagInfo actually shows 29 counts of amenity=dog_parking. I’ve only seen 
designated spots for dogs. Leaving a cat there might not be safe for either 
animal. 

Ant

> 20 авг. 2019 г., в 16:15, Jmapb via Tagging  
> написал(а):
> 
>> On 8/20/2019 4:57 AM, Andrew Davidson wrote:
>> On 20/8/19 6:24 pm, John Willis via Tagging wrote:
>  So let's standardize on a tag:
>> 
>> amenity=hitching_post
>> hitching_post=dog ?
>> 
>>> 
>>> Interestingly, one of the items they sell is a green 30x30cm marker
>>> to go on the sidewalk in front of the pole - literally a sign for the
>>> designated spot for dogs to wait.
>> 
>> Japanese dogs must be pretty cluey ;-)
> 
> Sounds like this one literally is a hitching post, so
> amenity=hitching_post would be fine. But ideally IMO we'd want something
> described by function more than form, so people wouldn't feel like the
> need to invent a new tag for each style. (A ring, a doghouse, a
> designated indoor room, a fenced pen...)
> 
> Actually, this reminds me of bicycle parking more than anything else...
> so amenity=animal_parking? Adding animal=dog (horse, camel, whatever)
> would mesh well with the existing use of the animal=* tag.
> 
> J
> 
> 
> ___
> 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 - traffic_calming=dynamic_bump

[Anton Klim]

Thanks for the proposal, this is something I haven’t heard of before!
Not sure if “bump” would be suitable for those that slide down beneath the 
surface? Maybe traffic_calming=dynamic/variable?

Regards
Ant

> 28 авг. 2019 г., в 21:54, "simson.gert...@gmail.com" 
>  написал(а):
> 
> Hello,
> 
> sorry it seems the html email type was not suitable for the mailing list. 
> Here is the email again in plain text:
> 
> I created a proposal. Please comment if you have comments.
> 
> Definition: A dynamic traffic calming whose impact depends on the drivers 
> actual speed
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:traffic_calming%3Ddynamic_bump
> 
> Best Regards,
> 
> Klumbumbus
> 
> 
> ___
> 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] Road blocks?

[Anton Klim]

Seeing the tag for the first time, but it's on the wiki so some router should 
support it. 
I usually drop a simple barrier=block on the way, with a fixme and check_date 
for an approximate works end date. 
Keep in mind that quite a lot of end user apps like mapsme and osmand only 
update data once in a while, so a temporary block might extend beyond what's 
intended. 

Ant

24.12.2018, 4:46, Graeme Fitzpatrick :

> Hi
> 
> Council are currently doing a lot of storm water drainage works in our area 
> so various roads will be closed off for some time (several months).
> 
> Probably a silly question I know, but I'm not assuming :-), but will dropping 
> one of these 
> https://wiki.openstreetmap.org/wiki/Tag%3Abarrier%3Djersey_barrier, each side 
> of the works, stop routers from directing traffic up that street?
> 
> 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

Re: [Tagging] Road blocks?

[Anton Klim]

A single barrier= node of your choice would generally block the way it’s 
dropped on. If the street/lanes are drawn with separate ways, you might need 
more nodes/a barrier= way.
Phil is right to point out there might be different conditions of passage, so 
adding the temporary footbridge would help pedestrian routing. 
Indeed merry Christmas to those celebrating.

Ant

> 25 дек. 2018 г., в 2:03, Graeme Fitzpatrick :
> 
> 
> Thanks fellas!
> 
>> On Mon, 24 Dec 2018 at 18:33, Anton Klim  wrote:
>> Seeing the tag for the first time, but it's on the wiki so some router 
>> should support it. 
>> I usually drop a simple barrier=block on the way, with a fixme and 
>> check_date for an approximate works end date.
> 
> No, I've never thought about the technicalities of how they actually work 
> either!
> 
> Would a single =block, block the full width of the road, or would it need one 
> in each lane?
> 
> Guess it might be a case of suck it & see! 
> 
>> Keep in mind that quite a lot of end user apps like mapsme and osmand only 
>> update data once in a while, so a temporary block might extend beyond what's 
>> intended. 
> 
> True. Osmand seems to update once every month or two (at least in Australia) 
> so there will be an overlap. However, these closures are expected to be in 
> place for ~8 months :-(, so shouldn't be that big an issue 
> 
>> On Mon, 24 Dec 2018 at 20:16, Philip Barnes  wrote:
>> I may be teaching you to suck eggs, but also take into account what the 
>> restriction applies to. If the route remains open to pedestrians/cyclists 
>> then use appropriate access tags, for example motor_vehicle=no rather than 
>> access=no.
> 
> All suggestions always gratefully accepted! :-)
> 
> Roads are cut to all private vehicles, Council vehicles can enter the work 
> zone but not get all the way through (as there's a 20' wide trench across the 
> road!). Pedestrians & cyclists can get through on one side only, across a 
> temporary footbridge - guess I need to add that in as well?
> 
> Thanks Graeme
> 
> PS Merry Christmas!
> ___
> 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] Allotments plot / lot tagging and ref?

[Anton Klim]

I think iD might be rendering refs now, unless I misremember. Using ref seems 
more logical than coming up with a ref replacement just for allotments. 

Ant

> 7 янв. 2019 г., в 0:37, Joseph Eisenberg  
> написал(а):
> 
> “One day plots may even be rendered, but I'm not holding my breath.”
> 
> I’m working on the SQL query right now... but I thought we should discuss 
> this here first.
> 
> Re: name=* for plots: I didn’t expect an individual plot to have a name. But 
> if this is possible it should be documented on the wiki page too.
>> On Mon, Jan 7, 2019 at 8:59 AM Paul Allen  wrote:
>>> On Sun, 6 Jan 2019 at 23:46, Joseph Eisenberg  
>>> wrote:
>> 
>>> The current wiki page for landuse=allotments
>>> (https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dallotments) states
>>> that one should "Use allotments=plot and/or boundary=lot for an
>>> individual plot and lot=number_of_plot for number of plot."
>> 
>> It has changed since I looked at it several months ago (or my memory of it 
>> has).  I don't
>> remember boundary=lot or lot=number_of_plot.
>> 
>>> However, the wiki page for allotments=plot
>>> (https://wiki.openstreetmap.org/wiki/Tag:allotments%3Dplot) states
>>> "You may want to use the ref=* to indicate the number assigned to your
>>> plot."
>> 
>> That I remember.  And found it to be of little value as it didn't render and 
>> wasn't displayed by iD.
>> 
>>> The other interesting fact is that the proposal page for
>> 
>> Ah, the proposal page.  Last time I looked it had a link to an example, 
>> created by the
>> proposer.  Which didn't use ref=* but did use name=*.  The name IS displayed 
>> by iD,
>> but isn't rendered.  So, for the sake of my sanity, I used name as well as 
>> ref so I could see
>> what I was doing.
>> 
>> I should also point out that the name of the plot in the example made it 
>> clear it was a memorial
>> plot (something like "Fred J Bloggs Memorial Plot").  Using the name of the 
>> person utilizing the
>> plot would possibly breach data protection legislation.  Just saying, for 
>> those tempted to do
>> that.
>> 
>>> allotments=plot and the wiki page both show this as an "approved" tag,
>>> however there were 8 opposing votes and only 9 approving votes in the
>>> 14 day voting period, so it should have been marked as rejected back
>>> in 2013. Perhaps the status should be changed to "in use", since it is
>>> used 11,000 times.
>> 
>> Yeah, the proposer was naughty.  But it's now a de facto tag anyway and 
>> should be documented
>> as such.  One day plots may even be rendered, but I'm not holding my breath.
>> 
>> 
>> -- 
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Changeset tag for issue closing

[Anton Klim]

Considering heated discussions usually follow object tags, I won't expect the 
same amount of people to argue about change set tags (I sometimes forget they 
exist).
Seems logical, although to me qa processing seems complicated to process/fit in 
a tag...

Ant

07.01.2019, в 22:51, 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Road blocks?

[Anton Klim]

Yep, looks like it might be a router data issue rather than a router issue. 
Maybe try OsmAnd Live if you have an android device, or find an alternative osm 
router that updates faster

12.01.2019, 0:15, Joseph Eisenberg :

> Graphhhopper does not update the database instantaneously. I believe you will 
> need to wait some time before the routing matches the database: days, not 
> hours.
> On Sat, Jan 12, 2019 at 9:09 AM Graeme Fitzpatrick  
> wrote:
>> 
>> 
>> On Tue, 25 Dec 2018 at 09:03, Graeme Fitzpatrick  
>> wrote:
>>> 
>>> Guess it might be a case of suck it & see! 
>> 
>> So, after a couple of weeks of experimenting & playing with various blocking 
>> options, then checking them with OSRM & GraphHopper (which incidentally, 
>> brings up some pretty strange results - I'm even tempted to ignore it's 
>> results altogether?) by attempting to route through the roadworks area, I 
>> can report back.
>> 
>> If anybody would like to experiment themselves, the spot I was using is 
>> here: https://www.openstreetmap.org/#map=18/-28.07477/153.43936, with the 
>> various blocks being positioned between house number 77 (Mountain View 
>> Avenue) at the western corner Ernie Tebb Park, & the unmarked crossing / 
>> painted island, between the Park & the lake.
>> 
>> I was then attempting to route from "12, Honeyeater Drive, Miami, Gold 
>> Coast, Queensland, 4220, Australia" to "20, Nobby Parade, Miami, Gold Coast, 
>> Queensland, 4220, Australia", which is a very simple, quite direct route.
>> 
>> Unfortunately, when I say that GraphHopper was giving strange results, 
>> especially for foot & bicycle, it was doing this: 
>> https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=-28.07561%2C153.43761%3B-28.07433%2C153.44100.
>> If this can't be seen, it has foot traffic walking North up Honeyeater 
>> Drive, East down Mountain View Avenue along the road, not the adjacent 
>> footpath, going the wrong way round the roundabout, continuing down & 
>> turning South into Babbler Court, then immediately coming back West along 
>> the Mountain View Avenue footpath till just before the roundabout, where it 
>> crosses Mountain View Avenue at the footway=crossing + crossing=unmarked, 
>> follows the round the corner into Nobby Parade, then crosses at another 
>> crossing, before continuing North along the footpath to the destination.
>> 
>> Bicycle routing is identical, except that it goes the correct way around the 
>> roundabout, before getting onto the footpath!
>> 
>> So FYI, the results of my testing were:
>> 
>> 1. single barrier=yes (on the road - the actual marked highway=tertiary); 
>> access=no: didn't render; doesn't stop vehicle, bike or foot access
>> 
>> 2. single barrier=block (on the road); access=no: rendered as dot only; 
>> doesn't stop vehicle, bike or foot access
>> 
>> 3. row of barrier=block across both lanes; access=no; rendered as row of 
>> dots; doesn't stop vehicle, bike or foot access
>> 
>> 4. barrier=bollard (one only on road); access=no: rendered as single dot 
>> only; doesn't stop vehicle, bike or foot access
>> 
>> 5. row of barrier=bollard across both lanes; access=no; rendered as row of 
>> dots; vehicles are blocked in OSRM, but GraphHopper still allows bike, foot 
>> & vehicle access
>> 
>> 6. single barrier=jersey_barrier (on road); access=no: rendered as dot only; 
>> doesn't stop vehicle, bike or foot access
>> 
>> 7. row of barrier= jersey_barrier  across both lanes; access=no; rendered as 
>> row of dots; doesn't stop vehicle, bike or foot access
>> 
>> 8. single barrier=gate (on road); access=no: rendered as dot only; doesn't 
>> stop vehicle, bike or foot access
>> 
>> 7. barrier=fence (across full width of road); access=no: rendered on both 
>> sides of the road, but not across the road itself; vehicles are blocked in 
>> OSRM, but GraphHopper still allows bike, foot & vehicle access
>> 
>> 8. barrier=gate in barrier=fence in middle of roadway; access=no on both; 
>> gate didn't render, fence still only visible on both sides of the road, but 
>> not across the road itself;  vehicles are blocked in OSRM, but GraphHopper 
>> still allows bike, foot & vehicle access
>> 
>> 9. barrier=ditch (across full width of road); access=no; didn't render; 
>> doesn't stop vehicle, bike or foot access
>> 
>> 10. Least favourable option by far :-( 
>> Split the road & cut a small (~5m) section out; shows as two road endings 
>> actually touching; vehicles are blocked in OSRM, but GraphHopper still 
>> allows bike, foot & vehicle access
>> 
>> Increase gap to ~20m; gap shown in road; doesn't stop vehicle, bike or foot 
>> access in either router, after a small gap did block OSRM?
>> 
>> Increase road gap to ~50m by cutting it at corner of Honeyeater Drive, so 
>> whole section of road has disappeared; everything is stopped from going that 
>> way, including foot & bike, even though there's a marked footpath along the 
>> side of the road?
>> 
>> Unless I've been doing somethin

Re: [Tagging] start_date variants

[Anton Klim]

I believe there was an (failed? Undocumented?) attempt to make 
building:buildyear a thing, but haven’t seen it used for a while. 


> 15 февр. 2019 г., в 14:44, Stephan Bösch-Plepelits  
> написал(а):
> 
>> On Fri, Feb 15, 2019 at 03:07:09PM +0100, Tobias Zwick wrote:
>> Sounds solid and already used quite a bit.
>> 
>> But wait, is it start_date:somekey or somekey:start_date?
>> 
> I would say somekey:start_date, because - in the case of buildings you also
> have:
> * building:levels=3
> * building:start_date=1990
> 
> It's - according to taginfo - more common, e.g.:
>  building:start_date 156 times
>  start_date:building 18 times
>  name:start_date 169 times
>  start_date:name 55 times
>  railway:start_date 745
>  start_date:railway 3087 (so that contradicts my argument)
> 
> greetings,
>Stephan
> -- 
> Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
> ,--.
> | Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
> | Projects:|
> | > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
> | > Urbanism: Radlobby Wien|
> | Contact: |
> | > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
> | > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
> | > Mastodon: @pl...@en.osm.town   |
> `--'
> ___
> 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] start_date variants

[Anton Klim]

I think those would mostly be historical uses. Considering it’s part of an 
abandoned proposal, don’t think there would be much new entries. 
Plus, buildyear implies you can specify a year, instead of a date, like you can 
for start_date and its possible offshoots. 

Ant

> 16 февр. 2019 г., в 10:22, Sergio Manzi  написал(а):
> 
> Actually building:buildyear is of much more widespread use than 
> building:start_date:
> 
> https://taginfo.openstreetmap.org/keys/?key=building%3Abuildyear -> 2051 
> objects
> https://taginfo.openstreetmap.org/keys/?key=building%3Astart_date -> 163 
> objects
> that's a 12.6:1 proportion...
> 
> The key is documented in the IndoorOSM proposal [1] and in a wiki page of 
> which I fail to understand the meaning [2].
> 
> Sergio
> 
> 
> 
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/IndoorOSM
> 
> [2] https://wiki.openstreetmap.org/wiki/Item:Q2952
> 
> 
>> On 2019-02-16 10:39, Anton Klim wrote:
>> I believe there was an (failed? Undocumented?) attempt to make 
>> building:buildyear a thing, but haven’t seen it used for a while. 
> ___
> 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] start_date variants

[Anton Klim]

Like in the thread opening email, where there is an amenity that occupies the 
whole building, we put amenity tags on the outline. 
I generally support adding more granularity to start_date, but feel like 
start_date:* might fit better than *:start_date. 

Anton Klim

> 16 февр. 2019 г., в 21:40, Sergio Manzi  написал(а):
> 
> Stephan, can you point to any such object in OSM where you find that 
> ambiguity?
> 
> I have the feeling that we could possibly discover a violation of the "One 
> feature, one OSM element" principle [1] in there...
> 
> Sergio
> 
> [1] https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
> 
> 
>> On 2019-02-16 22:01, Stephan Bösch-Plepelits wrote:
>> My suggestion was to use a prefix "building:" if the start_date of the
>> building differs from the start_date of the amenity. It is not very common
>> though right now, with only 163 uses. Only 9 have both start_date and
>> building:start_date.
> 
> ___
> 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] start_date variants

[Anton Klim]

There've been quite a lot of discussions lately about namespaces and indeed
current osm tagging is clunky in that regard.
not sure if relations are a good fix though

сб, 16 февр. 2019 г. в 23:07, Sergio Manzi :

> Yeah. The "*other*" solution could be to "*namespace everything*", so you
> could tag building:whatever_property_key_you_want and
> amenity:whatever_property_key_you_want, applied to the very same object.
> But we're probably too late for that and apparently many seems to hate this
> latter solution.
> On 2019-02-16 23:59, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>
> On 16. Feb 2019, at 23:49, Anton Klim  
>  wrote:
>
> Like in the thread opening email, where there is an amenity that occupies the 
> whole building, we put amenity tags on the outline.
>
> I agree with Serge here, when there is a problem where it is not clear to 
> what the tags refer, it is usually a modeling problem of mixing different 
> things up in one object, and a better solution than creating more specific 
> tags by prefixing them, would be to fix the model. It will not end at 
> start_date ;-)
>
> Cheers, Martin
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] airport check in counters

[Anton Klim]

The check in counters are generally quite numerous, so you’d need a detailed 
indoor map which I’m yet to see for an airport in osm. The wiki aeroways page 
mentions the undocumented amenity=check_in and security control. 

For arrival lounges, I think there were a number of “waiting area” proposals. 
Indoor=area is documented in the SIT wiki, validators (and editors/renderers) 
are generally useless at indoor things. 

Ant

> 31/03/2019, 5:50, Warin <61sundow...@gmail.com>:
> 
> Hi
> 
> Airport check in counters don't seem to have any way of mapping these.
> 
> As there is usually a number of them it is handy to know there proximate 
> location so your not dragging luggage from one end to the other.
> 
> Thoughts?
> 
> There are also 'arrival lounges' where people can wait for family/friends 
> arriving. These are less of a problem, but still it would be good to have a 
> method of tagging them.
> 
> Thoughts?
> 
> I have used the tag indoor=area, OSMInspector complains that this is not a 
> physical tag...
> 
> 
> ___
> 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] Avoid using place=locality - find more specific tags instead

[Anton Klim]

Deprecating a tag because it was misused would remove quite a lot of current 
osm tagging. 
I also think some of the examples you mention cannot be re-tagged without some 
proper research that’s not going to happen (do the locals call that place 
%name% because it was a crosssroads at some point or because there was a 
village nearby? Who knows). 
Using a lifecycle prefix is definitely a good idea, but there is simply no data 
to determine what to prefix in some cases. By all means, if one could add a 
more specific tag they should, but localities are a thing and place=locality 
can be used correctly. 

But it’s osm, so any tag you like, huh?

Ant

> 16/04/2019, 8:38, Joseph Eisenberg  написал(а):
> 
> We recently discussed place=locality, and I now believe this tag
> should be avoided, and perhaps deprecated.
> 
> To summarize, most of these features were added in North America from
> GNIS imports; almost 20% are in Alaska alone (>200,000!), and they
> were used for all sorts of features that are not populated places:
> abandoned hamlets, former mining camps, construction sites, railroad
> and highway junctions, former locations of Native Alaskan villages,
> etc.
> 
> Martin and Warin suggested to use abandoned:place=* for those which
> were former place=hamlet, =village, isolated_dwelling, etc.
> 
> Several people mentioned ways they have used this tag for a "place
> without population that has a name:" for example, to tag crossroads,
> hills, a wood, a field, a pair islands, a group of a few lakes, an
> informal landmark / route mark, an abandoned airstrip, a proposed
> airstrip, etc.
> 
> However, most of these suggested uses have other tags that could be
> more specific
> crossroads: highway=junction
> railway junction: railway=junction
> hill: natural=peak or natural=ridge or natural=hill
> wood: natural=wood
> field: landuse=farmland or =meadow
> islands: place=archipelago
> airstrip: proposed:aerodrome=airstrip + abandoned=yes;
> abandoned:aerodome=airstrip
> 
> Two of the examples need new tags created:
> 3 lakes with a name: needs a new tag, perhaps natural=lake_group as a
> multipolygon relation?
> An informal landmark (eg an old car wheel up on a tree) - perhaps
> there is something for this already.
> 
> I believe that place=locality was a reasonable idea when it was
> proposed in 2007, and few tags had been developed. But now, over 11
> years later, we have more specific tags for almost everything that is
> currently tagged this way.
> 
> My suggestion: check out all the features tagged with place=locality
> in your area. If they have a more specific tag or a more precise tag
> can be added, please remove the place=locality tag.
> 
> (If this results in the name no longer rendering in the
> Openstreetmap-carto, please check the list of issues and add a comment
> if you think that the feature should have a name label rendered on a
> general map: http://github.com/gravitystorm/openstreetmap-carto/issues
> )
> 
> Joseph
> 
> ___
> 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] Inland customs offices

[Anton Klim]

It seems like there was some cross copying on the wiki. 
There is another, older key, amenity=customs, which is actually used at border 
crossings (from what I’ve seen) to denote customs control. 
I am not sure why the amenity tag was deprecated (it also seems to be used more 
often than the office tag). A customs office is not necessarily a place where 
such control can be carried out and surely should be distinguished?


Ant

> 30 мая 2019 г., в 10:55, Joseph Eisenberg  
> написал(а):
> 
> That makes sense to me.
> 
>> On Thu, May 30, 2019 at 6:35 PM Jan S  wrote:
>> Hey everyone,
>> 
>> I've just noticed that the wiki at 
>> https://wiki.openstreetmap.org/wiki/Tag:government%3Dcustoms defines a 
>> customs building as "A structure near or at an international boundary where 
>> travelers and vehicles crossing the border are inspected."
>> 
>> Customs controls however take place inland, also, e.g. at river ports or in 
>> bigger commercial areas. There, lorries or containes pass customs control 
>> and are then sealed by the customs officials and may thus pass a border 
>> without further inspection of the content.
>> 
>> I propose that inland customs facilities be tagged as government=customs, 
>> too, and the wiki be modified accordingly.
>> 
>> Best,
>> Jan
>> ___
>> 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] Idea for a new tag: amenity=power_supply

[Anton Klim]

I am surprised this is not something that exists already (or is it?)
Wouldn't limit it to caravans though, would be equally useful for those
looking to charge electronics or power a tool of some sort.
Or is that power_supply?

Ant

пт, 21 июн. 2019 г. в 15:22, Michael Brandtner via Tagging <
tagging@openstreetmap.org>:

> Hi,
>
> I'm thinking about (and in fact, have already used about two times) a new
> tag: *amenity=power_supply*. It is meant for mapping places where you can
> get electrical power for a fee. They can be found at camping grounds and
> harbours. They have sockets you can use to get power and you can pay with a
> special card that you can buy at a shop (or maybe sometimes with credit
> cards or even coins, I'm not sure about that).
>
> The tagging scheme for this wouldn't really be new. You create a node at
> the location of the machine, similar how we already map
> amenity=water_point. For additional information about sockets etc., the
> already established tag power_supply=*
> can be used.
>
> Please note that this is not an amenity=charging_station. These devices
> are not meant for charging vehicles but for getting power for your boat or
> caravan while staying at a harbour or camping ground.
>
> By the way, the tag is not my invention. At the moment, it is already used
> 56 times.
>
> Do you think this is a good idea? I'd like to get your comments before
> starting an actual proposal process.
>
> Michael
> ___
> 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] Idea for a new tag: amenity=power_supply

[Anton Klim]

Guess it could be the same as fuel stations/hotels etc with extra
amenities: high-level tagging on the whole campsite pitch with a sub tag,
or nodes on actual power sockets for more detail.


пт, 21 июн. 2019 г. в 15:46, Philip Barnes :

> On Fri, 2019-06-21 at 15:33 +0300, Anton Klim wrote:
>
> I am surprised this is not something that exists already (or is it?)
> Wouldn't limit it to caravans though, would be equally useful for those
> looking to charge electronics or power a tool of some sort.
> Or is that power_supply?
>
> Certainly not limited to Caravans, we use electrical hookups on camp sites
> with our tent.
>
> This is not free, it is part of the charge for using the campsite, some
> will have pitches with power available or not, others will come and fit a
> circuit breaker if you pay for it.
>
> In the case of camp sites, should this not be a sub-tag of the campsite
> pitch proposal?
>
> 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

[Tagging] Feature Proposal - RFC - Lounges

[Anton Klim]

Hey everyone,

A prolonged waiting period spend sitting in a lounge gave me an opportunity
to send out the draft proposal for lounges, which can be found here:
https://wiki.openstreetmap.org/wiki/Proposed_features/Lounges

What is proposed:
A distinct amenity =* value
for lounges ([image: [W]] Lounge ),
usually used to describe a comfortable waiting area with optional
food/drink/other facilities, is proposed.

I was quite surprised to see no tag was already in wide use/agreed on, but
happy to be proven wrong if I missed it.
As usual with these things, suggestions/comments are very welcome.

Have a good weekend,
Anton
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Lounges

[Anton Klim]

Thanks for the reply Volker!

I had in mind a tag to describe the first 2 of the definitions given by you (a 
hotel “lounge” in my mind is more like an airport lounge than a plain lobby). 
For alcoholic bars the current tagging scheme appears sufficient so I didn’t 
mean to cover that. That is not to say that there isn’t alcohol served at the 
other 2 types of “lounges”.
I believe a general approach might be too complicated/convoluted, especially in 
the case of waiting rooms at gov offices and the like - more indoor mapping 
territory to me. 
The proposal was designed to cover all the other, usually transport-related 
glorified waiting rooms/lounges. It can be used for simple waiting rooms, but 
is really useful for lounges with added amenities, e.g showers, food.


Anton

> 9/06/2018, 22:20, Volker Schmidt :
> 
> The term Lounge has several distinct meanings, amongst them
> Airport Lounge
> Hotel Lobby
> Alcohol Bar
> 
> Which one do you have in mind?
> 
> If the first one, then maybe a more general approach should be taken to deal 
> with all kinds of waiting rooms (at a train station, at a bus station, at 
> airports, at a medical facility, at the tax office, ...
> An Airport Lounge is more or less modelled on a first-class train-station 
> waiting room. 
> 
> 
> 
>> On 9 June 2018 at 14:02, Anton Klim  wrote:
>> Hey everyone,
>> 
>> A prolonged waiting period spend sitting in a lounge gave me an opportunity 
>> to send out the draft proposal for lounges, which can be found here:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Lounges
>> 
>> What is proposed:
>> A distinct amenity=* value for lounges ( Lounge), usually used to describe a 
>> comfortable waiting area with optional food/drink/other facilities, is 
>> proposed. 
>> 
>> I was quite surprised to see no tag was already in wide use/agreed on, but 
>> happy to be proven wrong if I missed it.
>> As usual with these things, suggestions/comments are very welcome.
>> 
>> Have a good weekend,  
>> Anton
>> 
>> ___
>> 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] Feature Proposal - RFC - Lounges

[Anton Klim]

There are hotel lounges that offer showering facilities, but to access these 
lounges (executive lounges, clubs - they are called different names), you 
normally need to check in/be of elite status (hence the need for an access 
scheme described in the RFP). There are usually various amenities 
(food/drink/wlan) provided, if not showers, so a separate tagging scheme as 
suggested would be more convenient, rather than lounge=yes on the main node.

I feel like making this a PT tag limits it quite a bit, since some of these are 
a bit more than just a waiting room. Although admittedly most are connected to 
(public) transport, having a universal tag seems to allow better coverage 
overall. 

Anton

> 10/06/2018, 4:33, Johnparis :
> 
> I would think hotel lounges don't qualify, then, under what you're 
> describing. I've never seen one that offers showers. Hotel lounges are just 
> alcoholic bars in a hotel. You want a shower, you have to check in to the 
> hotel.
> 
> As a node or area (room?) within a public_transport=station, it makes sense 
> to me. I'd limit it to those. 
> 
> Are they really amenities? Maybe public_transport=lounge? Or 
> public_transport=station + lounge=yes ? Either way you would have the option 
> of wlan=yes/no, shower=yes/no, etc., though with the latter it's not clear 
> whether those options apply only within the lounge. 
> 
> 
> 
> 
>> On Sat, Jun 9, 2018 at 11:25 PM, Anton Klim  wrote:
>> Thanks for the reply Volker!
>> 
>> I had in mind a tag to describe the first 2 of the definitions given by you 
>> (a hotel “lounge” in my mind is more like an airport lounge than a plain 
>> lobby). 
>> For alcoholic bars the current tagging scheme appears sufficient so I didn’t 
>> mean to cover that. That is not to say that there isn’t alcohol served at 
>> the other 2 types of “lounges”.
>> I believe a general approach might be too complicated/convoluted, especially 
>> in the case of waiting rooms at gov offices and the like - more indoor 
>> mapping territory to me. 
>> The proposal was designed to cover all the other, usually transport-related 
>> glorified waiting rooms/lounges. It can be used for simple waiting rooms, 
>> but is really useful for lounges with added amenities, e.g showers, food.
>> 
>> 
>> Anton
>> 
>> 9/06/2018, 22:20, Volker Schmidt :
>> 
>>> The term Lounge has several distinct meanings, amongst them
>>> Airport Lounge
>>> Hotel Lobby
>>> Alcohol Bar
>>> 
>>> Which one do you have in mind?
>>> 
>>> If the first one, then maybe a more general approach should be taken to 
>>> deal with all kinds of waiting rooms (at a train station, at a bus station, 
>>> at airports, at a medical facility, at the tax office, ...
>>> An Airport Lounge is more or less modelled on a first-class train-station 
>>> waiting room. 
>>> 
>>> 
>>> 
>>>> On 9 June 2018 at 14:02, Anton Klim  wrote:
>>>> Hey everyone,
>>>> 
>>>> A prolonged waiting period spend sitting in a lounge gave me an 
>>>> opportunity to send out the draft proposal for lounges, which can be found 
>>>> here:
>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Lounges
>>>> 
>>>> What is proposed:
>>>> A distinct amenity=* value for lounges ( Lounge), usually used to describe 
>>>> a comfortable waiting area with optional food/drink/other facilities, is 
>>>> proposed. 
>>>> 
>>>> I was quite surprised to see no tag was already in wide use/agreed on, but 
>>>> happy to be proven wrong if I missed it.
>>>> As usual with these things, suggestions/comments are very welcome.
>>>> 
>>>> Have a good weekend,  
>>>> Anton
>>>> 
>>>> ___
>>>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Lounges

[Anton Klim]

I’m thinking some of the “passive resistance” could be avoided if we 
expanded/replaced “lounge” with “waiting_room/area”, and shifted tagging to PT 
(makes sense for the original proposal).
I’d argue general tourists can buy into some lounges as well. 

Anton

> 10 июня 2018 г., в 19:15, Johnparis  написал(а):
> 
> this is precisely why I raised the question of whether a lounge is an 
> amenity. it's not open to the general tourist population, for example, like a 
> bank or a pharmacy.
> 
> 
> 
>> On Sun, Jun 10, 2018 at 6:04 PM, Paul Allen  wrote:
>>> On Sun, Jun 10, 2018 at 4:16 PM, Yves  wrote:
>>> 
>> 
>>> Given the definition of an airport lounge given earlier (a waiting room 
>>> reserved for business or first class, operated by airlines company... ), I 
>>> think the concept is fairly concise.
>> 
>> Yes, the concept is concise.  As is my response: why bother?
>>  
>>> Now expanding this to hotels and dentists is not possible and maybe there 
>>> is no need to? 
>>> Stations are more the issue here if there is something there close to the 
>>> airport lounges.
>> 
>> In my youth, almost all railway stations had waiting rooms and none had 
>> lounges (as you intend the term).
>> Decades ago many stations switched to unmanned operation and the waiting 
>> rooms were closed (because of
>> vandalism in unattended stations) and still none had lounges.  These days, a 
>> handful of stations have lounges
>> but are outnumbered by stations with waiting rooms and/or bars/snack 
>> bars/cafes.
>> 
>> I doubt you'll find an airport that doesn't have a waiting room/area 
>> somewhere.  Probably also a bar or cafe.
>> Lounges are the expensive places catering to the rich customer 
>> (executive-class ticket or money to burn on
>> food/drink) rather than the ordinary traveller needing a place to sit.
>> 
>> Waiting rooms are present in hospitals, dentists' and doctors' surgeries.  
>> Also in job centres, council offices
>> and other places.
>> 
>> I can see tagging waiting rooms as being useful to the majority of data 
>> consumers who use those types of
>> organizations, even though those are a minority of data consumers.  This 
>> tagging seems to cater to a
>> minority of a minority.  If that's what you truly intend (it appears that it 
>> is) then I won't oppose it but nor will
>> I support it.  It's entirely possible I'd need to know if a station (or even 
>> airport) has a waiting room.  I don't
>> see me ever needing to know if it has a lounge (and for an airport it would 
>> be a selling feature of the
>> business-class ticket, so I'd know anyway).
>> 
>> So why bother?
>> 
>> -- 
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Lounges

[Anton Klim]

 Thanks everyone for your comments and suggestions.

I realised I might have bitten a bit too much with this tag, trying to
cover bare-bones waiting area and lounges under one key,
At this stage I am not expanding the tag to waiting rooms at
offices/institutions, rather focusing on the airport/hotel concept.
In light of this, I've also amended the proposed tagging to be more
specific, changing it to *airport_lounge *for the key.
I still feel like amenity is a good fit since it's a place people visit.

Andrew, many thanks for the reminder we have some tags for facilities such
as showers already. How would we go about covering things which are not
already in the scheme, e.g. whether food/drink is offered and of what type?
I don't think cuisine quite covers it.

Anton

2018-06-11 15:23 GMT+03:00 :

> *From:* Stephen Doerr 
> *Sent:* Monday, 11 June 2018 21:18
> *To:* Tag discussion strategy and related tools  >
> *Subject:* Re: [Tagging] Feature Proposal - RFC - Lounges
>
> My experience may be different from yours, but no one I know talks about a
> 'waiting room' in an airport. The general waiting area is quite often
> referred to as the 'departure lounge', in fact.
>
> Agreed. Though despite it being called a “departure lounge” I wouldn’t
> consider that an amenity=lounge. That’s just the airport trying to make
> themselves sound more fancy than they are.
>
> ___
> 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 - Lounges

[Anton Klim]

Indeed, I am myself somewhat opposed to a qualifier for each type of lounge
out there in the main key.
Hence why I set out with just amenity=lounge, not realising how many
conflicting meanings people assign to the word, which is why it probably
won't work.
In light of this, to avoid ambiguity and confusion, airport_lounge might be
a better option.

I could also potentially see the original amenity=lounge key, used with a
lounge=airport/rail/etc key.

Anton

2018-06-12 0:37 GMT+03:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> On 11. Jun 2018, at 23:08, Martin Koppenhoefer 
> wrote:
>
> >> On 10. Jun 2018, at 13:28, Paul Allen  wrote:
> >>
> >> If proposed as amenity=waiting_room I'd vote for it.  If proposed as
> amenity=lounge I'd vote against it.
> >
> >
> > +1
>
>
> taking it back, sorry. We could probably have all three, waiting room/area
> and lounge.
>
> Maybe waiting_lounge? airport lounge has the disadvantage that it doesn’t
> cover the same concept in train stations. Unlike airports it is not common
> there, but some (major) train stations have those lounges, usually access
> is limited (e.g. first class ticket, or some kind of membership in a
> frequent client program).
>
> While I agree that lounge alone can be ambiguous, the qualifier ideally
> should not be repeating the context but describe the concept, -0.6 to
> airport_lounge.
>
> 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] Feature Proposal - RFC - Lounges

[Anton Klim]

Thanks Martin. I feel like this is a separate, but generally more wide-ranging 
proposal considering the scale of facilities it potentially covers. 

Anton

13.06.2018, в 13:43, Martin Koppenhoefer  написал(а):

> I have set up 2 new proposals for waiting facilities, waiting room and 
> waiting area.
> See https://wiki.openstreetmap.org/wiki/Proposed_features/waiting_area
> and https://wiki.openstreetmap.org/wiki/Proposed_features/waiting_room
> 
> 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] Feature Proposal - RFC - Lounges

[Anton Klim]

Well, certainly, tags are abused all the times, especially when people can't 
find what they want in the editor. This is not the reason I'm thinking of 
changing the proposed tag to something already proposed here, like 
airport_lounge, transport_lounge or waiting_lounge (this might be a bit too 
close to Martin's proposal).
Comments on this are most welcome. 

Anton

12.06.2018, в 13:51, Paul Allen  написал(а):

> On Tue, Jun 12, 2018 at 11:20 AM, Anton Klim  wrote:
>> 
>> Hence why I set out with just amenity=lounge, not realising how many 
>> conflicting meanings people assign to the word, which is why it probably 
>> won't work.
> 
> I know you have already said you think a waiting room is different from your 
> proposal for a lounge and you're not
> interested (at the moment) in tagging for waiting rooms.  However, I can 
> foresee that unless there is
> amenity=waiting_room (or whatever we settle upon) then people WILL abuse 
> amenity=lounge (or whatever we
> settle upon) for waiting rooms.  Most of them won't deliberately intend to 
> abuse the tag, they'll just be
> going for the closest fit to what they're trying to map.  They probably won't 
> look at the wiki page telling them
> it's not for that purpose, it will be what the editor pops up in response to 
> what they're asking for.
> 
> A good rule of thumb: if the mailing list has as many conflicting 
> interpretations/opinions over a tag as this one
> has, it's likely to end up being used incorrectly in practise.  And then, a 
> few years down the line, we'll be looking
> for tagging to replace it.
> 
> -- 
> 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] Unresolved notes

[Anton Klim]

Hi Graeme,

Are you positive the notes were not there previously? Some of them are fairly 
old, and should’ve definitely been in the Notes layer of osm.org (which is 
optional).
Notes can sometimes be placed by people thinking it’s a personal note only 
visible to themselves. They also won’t appear in iD/won’t actively highlight 
the feature they refer to, so some mind bending might be required. E.g the last 
one, I’m guessing no speed limit was set on the road when the note was added. 

Anton

> 17 июня 2018 г., в 9:24, Graeme Fitzpatrick  
> написал(а):
> 
> Sorry, copied mixed info
> 
> This bit should show
> 
> Others are showing as a note apparently at a location 
> https://www.openstreetmap.org/note/1037676 but then it appears there's 
> nothing there to fix 
> https://www.openstreetmap.org/edit#map=17/-27.96197/153.40334 
> 
> Thanks
> 
> Graeme
> 
>> On 17 June 2018 at 16:21, Graeme Fitzpatrick  wrote:
>> G'day all
>> 
>> Just mentioned this on Bryan's iD thread, but he knows nothing about it.
>> 
>> This last week, I've seen "Unresolved note" markers suddenly appear all over 
>> the place - I've seen them in Europe, US & here in Australia where I know 
>> for a fcat that they definitely weren't showing ~a week ago?
>> 
>> eg https://www.openstreetmap.org/#map=10/-27.8696/153.1784&layers=N
>> 
>> Some seem to be problem / error reports from maps.me, but others don't 
>> appear to make much sense at all eg 
>> https://www.openstreetmap.org/note/968837#map=17/-28.12680/153.48452&layers=N
>> 
>> Others are showing as a note apparently at a location 
>> https://www.openstreetmap.org/note/1278528#map=17/-27.96197/153.40334&layers=N,
>>  but then it appears there's nothing there to fix 
>> https://www.openstreetmap.org/edit#map=17/-27.96197/153.40334
>> 
>> Anybody got any ideas about what they're all about & what we're supposed to 
>> do about them?
>> 
>> 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

Re: [Tagging] default access tag for driveways

[Anton Klim]

Is there a reason to add access tags to the way, when you have a barrier node 
that should already hold these tags (lift gate, bollard)?
Seems over complicated. 

Anton

> 30 июля 2018 г., в 9:07, Mateusz Konieczny  
> написал(а):
> 
> 27. Lipiec 2018 18:07 od joost.schou...@gmail.com:
> 
> You would only add "private" if there is signage, and only something else if 
> there is a right of way or something.
> 
> 
> I am adding access=private not only for cases with explicit signage but also 
> when access
> 
> is blocked (typically by a gate) or road is clearly private and used solely 
> to access given house.
> 
> 
> 
> At least in Poland explicit signage is extremely rare.
> 
> ___
> 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] Telephone exchange

[Anton Klim]

Hi,
The telecom tagging scheme (on wiki) definitely had a tag for telephone 
exchanges. 
For a building without windows, I’d suggest building=service


> 16 сент. 2018 г., в 8:48, José G Moya Y.  написал(а):
> 
> Hi!
> 
> Path 374362033 ( https://www.openstreetmap.org/way/374362033 ) is a building 
> with no windows in Calle del Fúcar, 28014 Madrid that contains a phone 
> exchange (originally it was a gigantic relay system for the phones of the 
> area, now probably replaced with smaller computers and microcontrollers). 
> It is tagged as "building=central office", a non-standard tag.
> I wonder if tagging it as "building=industrial" would be better, despite of 
> the whole neigbourhood being officially classified as "tertiary use" 
> (non-industrial). 
> 
> Or maybe "building=yes" would be just enough. Path 28996211 ( 
> https://www.openstreetmap.org/way/28996211 ) is a similar phone exchange 
> building, near Delicias, Madrid, enough old to be announced as "phone booths 
> that way" on the street. It is tagged as "building=yes".
> 
> Do you think I should change the tag on 374362033?
> 
> Yours, 
> José Moya
> Madrid
> 
> 
> ___
> 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=levee_breach_materials

[Anton Klim]

Do these have anything to identify them, like a ref?
3 words for a key seems like a mouthful to me, maybe 
emergency=levee_repair/materials.

Ant

21.09.2018, в 0:59, John Willis  написал(а):

> I ran into an interesting thing when mapping my local rivers. 
> 
> All of the rivers in my area have levees running 100% of their length from 
> the mountains to the coast, there are probably over 1000 linear KM of earthen 
> levees in the Tokyo region alone - 20mx10m levees (or bigger) along the outer 
> banks of all rivers. 
> 
> the small and the large rivers in my area have emergency levee repair 
> stations - hundreds of 1000kg concrete breakwater blocks (like you would see 
> in the ocean), a helicopter pad, and access to dirt/gravel. 
> 
> https://www.openstreetmap.org/way/550873664
> 
> They are situated on high ground, above flooding. 
> 
> After I found one, I found other collections of emergency breakwater supplies 
> along my river, and there are others along the larger rivers. 
> 
> I have never seen one of these purpose-built stations before. 
> 
> I am unsure of the landuse of such a station, nor is there a good tag for it. 
> 
> I thought up Emergency=levee_breach_materials
> 
> Thoughts?
> 
> javbw
> ___
> 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] Area of Firestations / Area of Ambulancestations

[Anton Klim]

I’m not sure I understand why it would be a landuse instead of an amenity tag 
on the area, or the other way round? Are landuses supposed to be for larger 
areas?

> 21 сент. 2018 г., в 9:58, Colin Smale  написал(а):
> 
> What about landuse=ambulance_station on the area? What would the landuse be 
> otherwise?
> 
>  
> Asking for a friend...
> 
> 
> 
>> On 2018-09-21 10:47, dktue wrote:
>> 
>> How about ambulance stations?
>> 
>> Should we tag the area with emergency=ambulance_station and the building 
>> with building=ambulance_station?
>> 
>> dktue
>> 
>>> Am 21.09.2018 um 03:23 schrieb Mike H:
>>> I've only mapped one station like this so far, but the area is actually 
>>> rendered on the map. https://www.openstreetmap.org/way/616033018
>>>  
>>> 
 On Thu, Sep 20, 2018 at 9:43 AM Tom Pfeifer  wrote:
 Yes of course, I've been doing this for long already.
 
 On 20.09.2018 14:06, Philip Barnes wrote:
 > Yes, just go for it. Makes perfect sense.
 > 
 > Phil (trigpoint)
 > 
 > On 20 September 2018 12:56:03 BST, dktue  wrote:
 > 
 > Hello,
 > 
 > I love how we map areas with amenity=school and buildings inside of 
 > it
 > with building=school. The same goes for amenity=hospital and
 > building=hospital.
 > 
 > What I'd like to have is the same schema for firestations: They often
 > have a large area and one or multiple buildings on it.
 > 
 > Should I go with amenity=fire_station for the area and
 > building=fire_station for the buildings inside of it?
 > 
 > Cheers,
 > dktue
 
 ___
 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency=levee_breach_materials

[Anton Klim]

Why not levee_repair?
Good to know they have a name and a list

2018-09-22 9:12 GMT+01:00 John Willis :

>
>
> On Sep 21, 2018, at 4:09 PM, Anton Klim  wrote:
>
> Do these have anything to identify them, like a ref?
>
>
> I found a sign cycling today.
>
> 奥戸防災ステーション
>
> Okudo (village) "Disaster prevention station"
>
> The "river" is implied - "river disaster prevention station" is a huge
> mouthful.
>
> The government has a PDF listing of a hundred of them and their addresses.
> These might be the very large stations with a highground and a helipad, not
> just a cache of breakwater blocks and gravel.
>
> I will investigate further, but levee_breach_materials might be the most
> flexible for uses elsewhere.
>
> http://www.mlit.go.jp/river/toukei_chousa/kasen_db/pdf/2018/4-2-3.pdf
>
>
> Javbw
>
>
> ___
> 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..

[Anton Klim]

Missed the point when direction= suddenly became a no go for traffic sign 
mapping. 


28.09.2018, в 3:51, 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] visa offices tags

[Anton Klim]

I believe the initial email was referring to a private-run visa assistance 
company, like VFS Global?
In the absence of a better tag I used office=company, but could see something 
like office=visa(_services) being suitable. 
It would need to be different for government agencies that might offer similar 
services in some countries. 

Ant

06.11.2018, 7:20, Allan Mustard :

> Migration services issue all visas in many countries, including tourist 
> visas. 
> 
> Sent from my iPhone
> 
> On Nov 6, 2018, at 9:34 AM, Warin <61sundow...@gmail.com> wrote:
> 
>> There is no OSMwiki on what government=migration is about. 
>> If you simply use the common definition of  'migration' then tourist do not 
>> fit. 
>> migration is the movement by people from one place to another with the 
>> intentions of settling
>> 
>> So a place that assist visas for tourist and business people would not 'fit'.
>> 
>> So I'd say .. office=government, government=migration does not handle this. 
>> Particularly when the office is a commercial firm, and I think has no 
>> government funding. 
>> 
>> 
>> On 06/11/18 14:11, Allan Mustard wrote:
>>> The office=government, government=migration tags already handle this, no?
>>> 
>>> Sent from my iPhone
>>> 
>>> On Nov 6, 2018, at 7:06 AM, Warin <61sundow...@gmail.com> wrote:
>>> 
 Lots of people apply for tourist visas. They are not immigrants, so 
 immigration does not fit all. 
 
 
 I don't know if that particular office only does immigration visas, 
 tourist visas or does any type of visa. 
 I would prefer a tag suitable for an office that could do any type of 
 visa, rather than having to find out which particular thing they do. 
 
 
 On 06/11/18 12:37, John Willis wrote:
> Amenity=immigration 
> 
> They handle visas and passports and other paperwork needs of legal 
> residents. 
> 
> This is not something for guests/tourists, but people (like me) who need 
> to handle paperwork to continue to live in the country. 
> 
> It is the inverse of an embassy. 
> 
> Javbw
> 
> On Nov 3, 2018, at 12:24 PM, Allan Mustard  wrote:
> 
>> Definitely not an embassy, and not a consulate, either!  More like a 
>> specialized travel agency that focuses only on visa applications.
>> 
>> On 11/3/2018 6:22 AM, Warin wrote:
>>> Hi, 
>>> 
>>> Node: Visalink Germany (4362535595) is tagged as an embassy. 
>>> 
>>> It is a commercial firm that arranges applications to the German 
>>> Embassy/Consulate for a visa, see 
>>> 
>>> https://www.visa-germany.co.za/ 
>>> 
>>> I think tags could be office=visa, country=DE, 
>>> website=https://www.visa-germany.co.za/ 
>>> 
>>> but not amenity=embassy, diplomatic=visa ... 
>>> 
>>> There are some 13 with the tag diplomatic=visa that may fall under this 
>>> same cloud. 
>>> 
>>> 
>>> ___ 
>>> 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 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

Re: [Tagging] visa offices tags

[Anton Klim]

Yep, that's the use case I was describing with VFS, I think people here might 
be conflating/confusing it with an immigration office, where you'd usually go 
when you already have a visa. 

I'm not sure about adding a lower-level company= key, but all for 
office=visa/visa_services. 

Ant

06.11.2018, 22:12, Warin <61sundow...@gmail.com>:

> The case I have is;
> 
> 1) this is a commercial firm - not a government 
> authority/branch/department/etc
> 2) it 'assist' people to obtain a visa
> 3) it is not at an airport/seaport/boarder
> 4) the visa is obtained before travel commences.
> 5) it is not within the country where the visa is used
> 
> What other thing/s have I left out?
> 
> I would like a tag that applies to;
> 
> 1) a commercial firm, not governmental
> 2) 'assist' with any visa types - so not limited to one type of visa
> 3) any location - not necessarily at an entry point.
> 4) any country or group of countries
> 
> To me that looks like
> office=visa
> country=* - possibly visa:country=* ?
> or
> office=company
> company=visa ?
> country=* - possibly visa:country=* ?
> 
> It is defiantly not
> office=government
> nor
> amenity=embassy
> 
> On 07/11/18 08:17, John Willis wrote:
>> 
>> Tourist visas are handled by different offices - usually at airports.
> 
> Not what I  want to tag, these would be governmental .. so office=government 
> would apply as a primary tag.
> 
> 
> ___
> 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] Government Archives

[Anton Klim]

I used office=government government=archive for these. 
Meaning of the office key is a bit wider for government offices, so I don’t 
really see an issue. 
On your best practice example, I don’t remember the government value for the 
building key, not sure we should make that a thing. Amenity=public building 
still strikes me as one of the least descriptive tags in osm.
While it’s certainly not a museum, I’d also argue it’s no library, since you 
don’t have the same degree of access, and it’s often not about reading a 
document but rather making inquiries. 

Ant

> 7 нояб. 2018 г., в 3:50, Warin <61sundow...@gmail.com> написал(а):
> 
> Just look at the key government the first thing to strike me was archive, the 
> key is meant to be used with office.
> 
> I don't think of government archives as offices... so what is in the data 
> base?
> 
> Well for Kew, UK
> building=government with amenity=public_building
> 
> There are quite a few archives with public building;
> Dublin, Ireland
> Engu, Nigeria
> New York, USA
> 
> 
> Some are just buildings;
> California, USA
> Normandy, France
> Cairo, Egypt
> Rarotonga, Cook Islands
> Abu Dhabi, UAE
> 
> 
> Some are Libraries;
> Chiang Mai, Thailand
> Adelphi, USA
> 
> 
> Some are museums;
> Tokyo, Japan
> Kabul, Afghanistan
> 
> Some are government offices;
> Zomba, Malawi
> Libreville, Gabon
> Gaborone, Botswana
> Dar es Salaam, Tanzania
> Delhi, India
> Bangkok, Thailand
> 
> 
> Would be nice to have some consistency?
> Usually at least one of these per country, some times several depending on 
> the size of the country.
> I found the above by searching for 'national archives'.
> 
> I think Kew has it best;
>  building=government with amenity=public_building
> 
> Humm that does not cover where there is one office you go to that is part of 
> a larger building having other offices.. do these exist?
> And if so .. are they really an office ... or more like a library or a 
> museum? I think a library, they are documents, very few 'artefacts'.
> 
> Thoughts?
> 
> ---
> There will be some that have 'off site storage'. These will be buildings, 
> perhaps best described as warehouses?
> So building=warehouse, access=private could be best?
> I think that is fairly clear.
> 
> ===
> PS It seems that as I hunt down one problem I come across several more 
> annoying ones ..
> though they decrease in numbers in the data base. I think I should buy some 
> blinkers and stop seeing these things!!!
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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