date:20181026

If we want to split hairs, we can point out that "embassy" is
technically an incorrect term for any building since an "embassy"
consists solely of people assigned to conduct diplomatic relations with
a foreign government, both resident and non-resident.  The "chancery"
https://en.wikipedia.org/wiki/Chancery_(diplomacy) is the office
building, complex, or office flat where the embassy operates.  I don't
think we want to be quite that doctrinaire (office=chancery, anyone?)
since "embassy" is the term in common if somewhat imprecise use for a
building or campus where a diplomatic mission operates.   

IMHO defining the ambassador's residence as an "office" would not be
wholly incorrect and only slightly mysterious to mappers and users of
our map, since the ambassador's residence is where a lot of work gets
done.  Half of my residence is devoted to space for official
entertaining, and I have a home office.  Also, WRT the point of certain
ambassadors' residences being historic manors, that's not really a big
issue since the vast majority of ambassadors' residences are neither
historic nor manors (my modest two-bedroom house certainly is neither,
and many ambassadors here in Ashgabat reside in apartments).  If there
is strenuous objection to my opinion on this, please offer an
alternative to office=diplomatic!

So here is where I sense we are 24 hours later, on Day 6:
a) consulates are not embassies;
b) neither embassies nor consulates are amenities;
c) embassies and consulates are government offices, but there is a trend
toward thinking office=diplomatic is a better choice than
office=government; and
d) the office=diplomatic tag in tandem with diplomatic=* would meet OSM
guidelines and support more accurate mapping.

If my sense of growing consensus is correct, I suggest that diplomatic=*
would include only [embassy, consulate, non-diplomatic]. The Wikipedia
article on diplomatic missions is not bad with respect to its
descriptions of different types of diplomatic missions:
https://en.wikipedia.org/wiki/Diplomatic_mission.  It also offers a
potentially neat solution for dealing with the non-diplomatic
representations of Taiwan and the United States in each others'
countries and other non-diplomatic representations, such as the Taliban
office in Doha.  I think limiting the number of options for diplomatic=*
to three would simplify mapping (and avoid confusing mappers not steeped
in the lore of diplomacy); the particular type of diplomatic mission is
in any case reflected in the name=* tag and needs not be duplicated in
the diplomatic=* tag (e.g., "High Commission of Malaysia", "Embassy of
Poland", "U.S. Interests Section", "Consulate General of Japan").  If
the status of a mission changes (e.g., the upgrade of the U.S. Interests
Section in Havana to an embassy), changing the name would suffice; no
re-tagging would be necessary.

There is a recurring sentiment in the discussion to add
diplomatic:services:*=[yes/no].  From my POV the services listed would
consist of [immigrant visas, non-immigrant visas, citizen services]. 
Those are the broad categories of services consulates and embassies
offer their clienteles. For instance, if the consular section of an
embassy or a consulate offers non-immigrant visas, it usually offers all
types of them (tourist, student, academic exchange, temporary work,
etc.).  Yes, there are exceptions, but that's what websites are for, and
I don't think it is OSM's job to delve so deeply in the details in order
to let Mexican migrant farm workers know that H1B visas are only
available via the American Consulate General in Ciudad Juarez.  Our
solution to this is to add the website URL for the convenience of OSM
users. All embassies and consulates offer services to commercial
interests of their fellow countrymen (or at least, they are supposed to)
so I see no need to add diplomatic:services:commercial=[yes/no].  In
those cases where an embassy includes a separately officed trade
representation (as Russia tends to do), the purpose of that mission is
obvious from the name=* tag.

apm-wa

P.S.  Regarding the question posed overnight as to whether one may
simply drop in on an ambassador's residence, any of you who are
contributing substantively to this discussion are welcome to drop by my
residence in Ashgabat any time you are in town :-)  Just please call
ahead to make sure I'll be home.

On 10/27/2018 1:13 AM, Daniel Koć wrote:
> W dniu 26.10.2018 o 22:08, Eugene Alvin Villar pisze:
>>
>> On the other hand. diplomatic offices and services encompass a range
>> that is much too narrow such that I don't think having diplomatic=*
>> as a primary key seems appropriate. I would prefer if we just have
>> the office=diplomatic + diplomatic=* tag combination instead. This
>> nicely parallels and complements the office=government + government=*
>> tag combination[1] that we already have, but instead applying to
>> foreign governments.
>>
>> [1]

Re: [Tagging] mast / tower / communication_tower (again)

On Sat, 27 Oct 2018 at 10:28, Greg Troxel  wrote:

>
> So where I think we are is:
>
>   there is almost zero support for the notion that guy wires or not is
>   critical and therefore these must not be part of definitions.  (Maybe
>   just Graeme.)
>

Sorry if I sound pedantic about it - I'm not an engineer of any sort, I'm
just working off the definitions shown on the tower wiki page, & many other
spots found by a mast v tower Google search eg

https://en.wikipedia.org/wiki/Guyed_mast

A *guyed mast* is a tall thin vertical structure
 that depends on guy lines
 for stability. The mast itself has
the compressive strength to support its own weight, but does not have the
shear strength to stand unsupported, and requires guy lines to resist
lateral forces such as wind loads  and
keep it upright

https://en.wikipedia.org/wiki/Radio_masts_and_towers

The terms "mast" and "tower" are often used interchangeably. However, in
structural engineering terms, a tower is a self-supporting or cantilevered
 structure, while a mast
 is held up by stays or guys
. Broadcast engineers in the UK use
the same terminology.

http://braziltowercompany.com/en/mast-or-tower.html

When discussing telecommunication antennas, the words “mast” and “tower”
are often used interchangeably. However, structurally, they are not the
same thing.
A mast is an antenna held up by stays or guy-wires, while a tower is a
self-supporting structure or is held up on one end only. Often, the term
“tower” is used when the antenna is attached to the ground, while “mast” is
used when the antenna is mounted onto another structure like a building or
a tower.

>   There are really multiple sorts of things we are talking about:
>
> A) towers that are more than for antennas, like Tokyo, Killesberg,
> Eiffel, and other similar things that aren't really buildings but
> which have a significant purpose beyond holding an antenna up high
>
> B) things that support antennas that are big enough that a person --
> almost certainly a professional antenna repairer/installer or tower
> maintainer -- can climb up inside of, or stand on some top platform.
> Usually lattice or some sort of >1.5m diameter tube.
>
> C) things that support antennas that have lattice or foot platforms
> and can be climbed by people externally, sort of like a ladder, with
> a climbing harness, again only by trained people for repair/install.
> Like Rohn 65.  Probably includes 30cm tubes that have climbing
> protrusions.
>
> D) things that support antennas that are small enough that no person
> can climb the outside.  Ranging from 2cm diamater to maybe 20cm.
>
> In my usage
>   A is a kind of tower
>
>   B and C are "antenna tower" (separate from the A type tower) in the
>   US.  I gather in the UK B is tower and C is mast.
>
>   D is a mast in the US
>
> I realize many here call A and B tower, and C and D mast.
>
> B and C are often different only in scale.  For example, B coudl be
> triangular lattic that's 1.2m on a side, and C could be 0.5m on a side.
> Once you can climb inside, one you can't.  But they are almost the same
> thing.
>
> Perhaps the C tubes/steps belong in D.  It is arbitrary.
>
> With respect to guys, I would expect A and B to be almost never guyed,
> and C sometimes guyed (especially as it gets tall), sometimes not.  D I
> would expect to be often short and not guyed, or taller and guyed.
>
> So how we want to group and label these is really arbitrary.   But it
> would be good if we agree on the 4 groups of reality and then group
> them, and stop saying that guyed/not is critically important.
>

OK, but can you translate all of that into a very simple one-line
description that a non-engineer layman, looking at an aerial photo, can say
Yep, I'll call this one a man_made=mast, but this one over here is a
man_made=tower? :-)

Thanks

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

Re: [Tagging] Wastewater Plants

On Sat, 27 Oct 2018 at 09:17, Clifford Snow  wrote:

>
> On Fri, Oct 26, 2018 at 2:36 PM François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> Hi
>>
>> That's a good idea, other components of wastewater treatement plants
>> should be mapped the same way
>> Nevertheless, man_made isn't appropriate for that.
>>
>> wastewater=* or at least water=* should be used for such values,
>> shouldn't you?
>>
>> wastewater as a key is used 100 times according to  taginfo. I like your
> suggestion of using wastewater or even wastewater_plant as a key with the
> various components as values of that key. That works better than having the
> values as part of the man_made key. With 50K man_made=wastewater_plant
> there are a number that could be improved in OSM if we had better tagging.
>

Does sound good.

Would you also change the main  man_made=wastewater_plant listing?

Maybe wastewater=plant / facility?

Thanks

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

Re: [Tagging] mast / tower / communication_tower (again)

2018-10-26 Thread Kevin Kenny

On Fri, Oct 26, 2018, 20:05 Warin <61sundow...@gmail.com> wrote:

> On 27/10/18 02:41, SelfishSeahorse wrote:
> > On Fri, 26 Oct 2018 at 08:23, Martin Koppenhoefer
> >  wrote:
> >> On the other hand, speaking about “numbers”, those are probably facts
> and not protectable by copyright
> > If i'm not mistaken, numbers aren't protected by copyright, but a
> > compilation of numbers (i.e. a database) can be protected; if not by
> > copyright then by so-called database right. See:
> >
> >
> https://www.esa.int/About_Us/Law_at_ESA/Intellectual_Property_Rights/Copyright_and_databases
> > https://en.wikipedia.org/wiki/Sui_generis_database_right
>
> US law does not apply everywhere.
>

Obviously, since those articles are about a sui generis database right that
US law does not recognize.

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

Re: [Tagging] mast / tower / communication_tower (again)

2018-10-26 Thread Greg Troxel

Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 26. Oct 2018, at 01:57, Greg Troxel  wrote:
>> 
>> for all things which are not buildings and basically exist to support
>> antennas, and avoid the tower/mast word choice, which is pretty clearly
>> contentious and/or confusing.
>
> what about this: 
> https://upload.wikimedia.org/wikipedia/commons/1/11/Killesberg_Tower.jpg

That does not have as the almost entire purpose to support antennas.
There is substantial effort/expense to make it suitable for people in a
touristy way.  So I would definitely not call that
"antenna_support_structure".  And it's tall (that's the point) and not a
building, so calling in man_made=tower seems right.

> this is not a building, neither by the German nor by the English
> definition, but at least for Germans it is a tower.  I would not
> require for towers to be a building (which at a minimum should provide
> some enclosed space).

fair enough.  And I'm fine with this being tower in a world where
antenna supports are something else.

So where I think we are is:

  there is almost zero support for the notion that guy wires or not is
  critical and therefore these must not be part of definitions.  (Maybe
  just Graeme.)

  There are really multiple sorts of things we are talking about:

A) towers that are more than for antennas, like Tokyo, Killesberg,
Eiffel, and other similar things that aren't really buildings but
which have a significant purpose beyond holding an antenna up high

B) things that support antennas that are big enough that a person --
almost certainly a professional antenna repairer/installer or tower
maintainer -- can climb up inside of, or stand on some top platform.
Usually lattice or some sort of >1.5m diameter tube.

C) things that support antennas that have lattice or foot platforms
and can be climbed by people externally, sort of like a ladder, with
a climbing harness, again only by trained people for repair/install.
Like Rohn 65.  Probably includes 30cm tubes that have climbing
protrusions.

D) things that support antennas that are small enough that no person
can climb the outside.  Ranging from 2cm diamater to maybe 20cm.

In my usage
  A is a kind of tower

  B and C are "antenna tower" (separate from the A type tower) in the
  US.  I gather in the UK B is tower and C is mast.

  D is a mast in the US

I realize many here call A and B tower, and C and D mast.

B and C are often different only in scale.  For example, B coudl be
triangular lattic that's 1.2m on a side, and C could be 0.5m on a side.
Once you can climb inside, one you can't.  But they are almost the same
thing.

Perhaps the C tubes/steps belong in D.  It is arbitrary.

With respect to guys, I would expect A and B to be almost never guyed,
and C sometimes guyed (especially as it gets tall), sometimes not.  D I
would expect to be often short and not guyed, or taller and guyed.

So how we want to group and label these is really arbitrary.   But it
would be good if we agree on the 4 groups of reality and then group
them, and stop saying that guyed/not is critically important.

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

Re: [Tagging] mast / tower / communication_tower (again)

2018-10-26 Thread Greg Troxel

SelfishSeahorse  writes:

>> For an example of something used in communications (an American thing,
>> but totally normal and other countries surely have equivalent things
>> with the same characteristics):
>>
>>   http://www.rohnnet.com/rohn-65g-tower
>>
>> which says right there can be up to 500 feet when guyed and 80 feet not
>> guyed.  But it's the same thing in both cases -- it just needs more
>> support when taller where the forces get bigger.
>
> I'd call this is a -- either guyed or not guyed -- mast (because there
> is no internal access).

I'm ok with that, as long as we realize that we are defining words to
not line up with US usage.  That's fairly normal, but we should be clear
that we are doing it.

>> As I said earlier, things that are maybe 10cm in diameter are usually
>> called masts.  These are very minor and not really used in
>> telecom/broadcasting.
>
> Do you call this [1] a mast in the USA?
>
> [1]: https://commons.wikimedia.org/wiki/File:LeifersexTimZentrum.jpg

Yes.  I (a ham radio operator) would call that a mast, because it isn't
lattice (like Rohn 65).  But it's on the large/strong end of mast, vs a
2" / 5 cm tubing section.  The general public would call that "cell
tower", but then again they would refer to cell antennas bolted onto the
top floor of a building "cell tower" also - for them, it's a functional
term.  But most amateur radio people would call it tower or mast if just
asked "what's that", and almost all that said tower if you then said
"but really, is it a tower or a mast", would say "well, good point, it's
just a mast, but it's on the upper edge of mast ".

>> So maybe we just need
>>
>>   man_made=antenna_support_structure
>>
>> for all things which are not buildings and basically exist to support
>> antennas, and avoid the tower/mast word choice, which is pretty clearly
>> contentious and/or confusing.
>
> I'm not very convinced because that would mean that everything from
> this tiny mast on a roof [1] to the Tokyo Tower [2] would be tagged
> man_made=antenna_support_structure.
>
> [2]: https://en.wikipedia.org/wiki/Tokyo_Tower

I really mean things that have almost no other purpose.  That structure
is also a tourist attraction, and it seems to have been built for that.
So I would not call it antenna_support_structure.

Here's a photo of something near me for TV, with no other purpose (other
than other communication stuff also put on it).

http://gallery.bostonradio.org/2003-05/needham-towers/100-01179-med.html

This is definitely antenna_support_structure.

But I don't really expect people to like this proposal.

___
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

On Sat, 27 Oct 2018 at 08:44, Peter Elderson  wrote:

> I would not tag that as a crossing for pedestrians at all.
>

Why not, Peter?

It is designed for wheelchairs, people with prams etc to easily get from
one footpath across to the next footpath, without having to get over a kerb.

Thanks

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

Re: [Tagging] mast / tower / communication_tower (again)

2018-10-26 Thread Warin


On 27/10/18 02:41, SelfishSeahorse wrote:

On Fri, 26 Oct 2018 at 08:23, Martin Koppenhoefer
 wrote:

On the other hand, speaking about “numbers”, those are probably facts and not 
protectable by copyright

If i'm not mistaken, numbers aren't protected by copyright, but a
compilation of numbers (i.e. a database) can be protected; if not by
copyright then by so-called database right. See:

https://www.esa.int/About_Us/Law_at_ESA/Intellectual_Property_Rights/Copyright_and_databases
https://en.wikipedia.org/wiki/Sui_generis_database_right


US law does not apply everywhere.


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

Re: [Tagging] Standardizing Mapillary tags and keys

Hello,

Le 27. 10. 18 à 00:33, Christopher Beddow a écrit :
> 1. when the source for an OSM changeset is from street-level imagery = 
> `source=mapillary` (this is mostly standard already)

I hope that you are talking about changeset tag and not filling
all objects with a source tag like we did before changeset tag
for changeset tag : yes
for source tag, no
the issue is that the next mapper use another source
to fill another tag, nobody (and no tools) enforce him to change
the source tag. did he need to add his source to the list ?
a object with at version #100 'll become very ugly.

> 2. when the Mapillary image key is known and used for creating or 
> editing a specific feature, such as when the image is currently being 
> viewed (like in pic4review), say it's key is `HytC6pfza--epnSXhnqfkw`, 
> then tag with `mapillary=HytC6pfza--epnSXhnqfkw`

why not... but it look like per object tag... so I don't see
what the advantage of link every picture to every osm object.
if a mapper want to review the mapillary route, then it load the 
mapillary layer, isn't it ?
ot the net step is to add all mapillary object id that show
the osm objet ?
I understand that 'll help a lot of machine learning but osm is not
the right database to make picture-2-object-found-in-this-picture link
I also dislike the ideal that we need to get all the history as object 
tag. let's take an example : a see a building, one id.
I fill the number of level, one id for the picture that show the levels.
I fill the roof shape, one id for the picture that show the roof.
I fill the architect tag, one id for the panel of this info.
I fill the building start date, one id for the panel of this info
so every tag may need a mapillary id tag, date tag, source tag and layer 
tag... that very ugly... and for what ? what's the advantage to get as
a tag the mapillary id of the picture that show the building startdate ?

> 3. The Mapillary timestamp is important, but we don't encourage exposing 
> exact timestamps for privacy, only the day. So we can tag 
> `mapillary:date=-MM-DD` from the image time stamp.

as a changeset tag, great idea.
as a objet tag, bad idea
and for privacy reason, we don't need at all to known that the building 
have been see on the 2018-10-27. 2018-10 is for sure enough. and maybe 
2018, depending of what you map (a building is build for 100 years,
a shop owner/name/brand may change very often.)

For privacy reason, some of us also wait a opensource mobile app :)

> 4. when the Mapillary source is a traffic sign from a traffic vector 
> tile/API then it should have a different key, based on our data 
> detection key. Something like: 
> `mapillary:data=n932k14cey1nyzejz5zsilzirc` and 
> `mapillary:layer=trafficsigns`

I dislike. if you have several id, make several id range
in osm, node/way/relation have several id, but if you saif id n1,
everybody understand you talk about the node and w1 is the way 1.
so mapillary id maybe in the form picture for a picture,
sign for the traffic sign id, and another other prefix
you need depending of how many layers you have.

> 5. when the Mapillary source is from a non-traffic sign data source (for 
> example, we are looking at getting an overlay of sidewalk lines) then 
> `mapillary:data=eyhthsypwnzuxymdunbwsktktu` with the key of the map 
> feature again and the layer indicated with `mapillary:layer=lines`

mapillary=line is enough

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

Re: [Tagging] Standardizing Mapillary tags and keys

On Sat, Oct 27, 2018 at 6:34 AM Christopher Beddow <
christop...@mapillary.com> wrote:

> Is there any critique of these ideas?
>

I think these tags are only appropriate as changeset tags and never as tags
on actual map objects (nodes, ways, relations).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

On Sat, 27 Oct 2018 at 06:32, Daniel Koć  wrote:

> It matches nicely, indeed, but on the other hand this is probably not an
> office:
>
> https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Dambassadors_residence
>
I'd agree that the residence is probably not an office=.

We've agreed that tagging the "embassy" / residence as landuse= or
building= won't work because of those cases that it's only a flat / unit,
not a freestanding building.

What's that leave us with?

government= with debate over whether that means host or sending govt, or

amenity= (probably diplomatic)

Have I missed any options? :-)

Thanks

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

Re: [Tagging] Wastewater Plants

2018-10-26 Thread Clifford Snow

On Fri, Oct 26, 2018 at 2:36 PM François Lacombe 
wrote:

> Hi
>
> That's a good idea, other components of wastewater treatement plants
> should be mapped the same way
> Nevertheless, man_made isn't appropriate for that.
>
> wastewater=* or at least water=* should be used for such values, shouldn't
> you?
>
> wastewater as a key is used 100 times according to  taginfo. I like your
suggestion of using wastewater or even wastewater_plant as a key with the
various components as values of that key. That works better than having the
values as part of the man_made key. With 50K man_made=wastewater_plant
there are a number that could be improved in OSM if we had better tagging.

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

On Sat, Oct 27, 2018 at 4:32 AM Daniel Koć  wrote:

> W dniu 26.10.2018 o 22:08, Eugene Alvin Villar pisze:
>
>
> On the other hand. diplomatic offices and services encompass a range that
> is much too narrow such that I don't think having diplomatic=* as a primary
> key seems appropriate. I would prefer if we just have the office=diplomatic
> + diplomatic=* tag combination instead. This nicely parallels and
> complements the office=government + government=* tag combination[1] that we
> already have, but instead applying to foreign governments.
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:office=government
>
>
> It matches nicely, indeed, but on the other hand this is probably not an
> office:
>
> https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Dambassadors_residence
>

True, this is not an office. An ambassador/diplomat's residence enjoys the
same extraterritorial rights and privileges as other diplomatic facilities
like embassies and consulates.

But this actually implies that diplomatic=* itself is not a good primary
key. You really do not expect citizens of either the host or the sending
country to just visit an ambassador's residence unannounced and without
invitation. (Maybe you can visit it if the ambassador is hosting a party
and you're invited.) Therefore, such residences should be rendered
differently from embassies and consulates and more like how other notable
residences are rendered (maybe like the White House or Buckingham Palace).
This implies that using diplomatic=ambassadors_residence needs a different
primary tag than office=diplomatic depending on the actual form of the
residence. The residence can be a manor (historic=manor) such the U.S.
ambassador's residence in Buenos Aires[1], a regular house (building=house)
such as the Argentinian ambassador's residence in London[2], or a hotel
suite (tag nonexistent, unless we use the Simple Indoor Tagging scheme)
such as the U.S. ambassador to the UN's residence in New York[3].

[1] https://en.wikipedia.org/wiki/Bosch_Palace
[2] https://en.wikipedia.org/wiki/49_Belgrave_Square
[3]
https://en.wikipedia.org/wiki/Residence_of_the_United_States_Ambassador_to_the_United_Nations
___
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 Peter Elderson

I would not tag that as a crossing for pedestrians at all.

Mvg Peter Elderson

> Op 27 okt. 2018 om 00:14 heeft Graeme Fitzpatrick  het 
> volgende geschreven:
> 
>> On Sat, 27 Oct 2018 at 01:01, Tom Pfeifer  wrote:
>> On 26.10.2018 16:41, Robert Skedgell wrote:
>> > On 26/10/18 11:44, 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.
>> > 
>> > An unmarked crossing may have no road markings or signs, but if there is
>> > tactile paving and/or a raised/lowered/flush kerb on the footway
>> > (sidewalk), how else would one tag it?
> 
> 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
> 
> Any other suggestions?
> 
> 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] 2 meaning for crossing=zebra

2018-10-26 Thread yo paseopor

Hi
Here is my opinion about that

If your query crossing in taginfo you may find 10 main values [1]:

uncontrolled > 668.448 but with marks (generic). I think they might be
zebra crossings.
zebra > 541.412
traffic_signals > 520.238 with traffic lights
unmarked > 146.241 without marks of any kind but it is not forbidden to pass
island > 52.437 big crosswalk with a traffic island at the middle
no >9.942 forbidden to cross (generic)
marked > 8.930
yes > 4.006 (most generic)
toucan > 2.058
pelican > 1964
puffin > 116

Let's reorder

no

yes
controlled...with traffic signals?
uncontrolled but
marked
unmarked

island

animal stuff (ref)
zebra
pelican
toucan
puffin
tigger
panda
pegasus
...

All the animal stuff is British. They called the crossing like with some
characteristic thing of some animals.

[2] Zebra: with black and white poles called Belisha Beacons. In the UK
they are uncontrolled but marked.
[3] Pelican:(previously pelicon crossing, which stood for "pedestrian light
controlled crossing"). Crossing with traffic lights and a button to cross.
Controlled traffic sign crossing.
[4] Panda:As pelican but with a "light traffic light" with two lights for
drivers and only the word cross for the pedestrian people
[5] Tigger: iniatially was yellow and black. Now are the crossing for
bicycles. Attached to the zebras
[6] Toucan: "Since two-can, both pedestrians and cyclists, cross together,
the name "toucan" was chosen." Big sense of humour. If you take a Tigger
and a pelican then you will have a Toucan crossing. Controlled with traffic
lights and a button. If the button and the pedestrian/cyclist traffic light
is at the same place when you start to crossing and not in the opposite it
is called puffin crossing [7]
[8] Pegasus: for horses

So... what about OSM might be in all the countries

I think OSM can describe the crossing with one key, and then can explain
how it is called the crossing with other key so

crossing=no
crossing=yes (most generic)
crossing=controlled is with traffic signals or with police people or similar
crossing=traffic_light is with traffic lights. So implies
crossing=controlled
crossing=uncontrolled can be crossing=marked or crossing=unmarked . So one
of them implies crossing=uncontrolled

If there is a traffic island in the crossing you can tag crossing=island

and then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other
value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of
panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated

crossing_ref is a good key for describe better the crossing

I would change all the crossing=animal stuff to crossing_ref and then
crossing=technical description.

Salut i passos de vianants (Health and crossings)
yopaseopor

[1] https://taginfo.openstreetmap.org/keys/crossing#values
[2] https://en.wikipedia.org/wiki/Zebra_crossing
[3] https://en.wikipedia.org/wiki/Pelican_crossing#Details
[4] https://en.wikipedia.org/wiki/Panda_crossing
[5] https://en.wikipedia.org/wiki/Zebra_crossing#Tiger_crossing
[6] https://en.wikipedia.org/wiki/Toucan_crossing
[7] https://en.wikipedia.org/wiki/Puffin_crossing
[8] https://en.wikipedia.org/wiki/Pegasus_crossing
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Standardizing Mapillary tags and keys

2018-10-26 Thread Christopher Beddow

Hello! I want to propose some new keys for the `mapillary=*` tag. I am
looking for input on these, then would like to push for approving them (and
update the Wiki). This will be helpful as some street-level imagery tools
like Pic4Review automatically add tags.

At State of the Map US there was a side discussion on how to let
street-level imagery users, such as on Mapillary and OSC, know that their
images are being used for editing OSM. This will encourage people to
capture more images, spread awareness of OSM, and perhaps encourage them to
start editing the map as well if they are not already.

My tag plan:

1. when the source for an OSM changeset is from street-level imagery =
`source=mapillary` (this is mostly standard already)

2. when the Mapillary image key is known and used for creating or editing a
specific feature, such as when the image is currently being viewed (like in
pic4review), say it's key is `HytC6pfza--epnSXhnqfkw`, then tag with
`mapillary=HytC6pfza--epnSXhnqfkw`

3. The Mapillary timestamp is important, but we don't encourage exposing
exact timestamps for privacy, only the day. So we can tag
`mapillary:date=-MM-DD` from the image time stamp.

4. when the Mapillary source is a traffic sign from a traffic vector
tile/API then it should have a different key, based on our data detection
key. Something like: `mapillary:data=n932k14cey1nyzejz5zsilzirc` and
`mapillary:layer=trafficsigns`

5. when the Mapillary source is from a non-traffic sign data source (for
example, we are looking at getting an overlay of sidewalk lines) then
`mapillary:data=eyhthsypwnzuxymdunbwsktktu` with the key of the map feature
again and the layer indicated with `mapillary:layer=lines`
please share any input with me!

Is there any critique of these ideas?

best,

Chris Beddow | Solutions Engineer @ Mapillary
___
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] lgbtq=primary ? Re: Out of the bars and onto the map: An lgbtq:= tagging scheme?

On Sat, 27 Oct 2018 at 01:26, Rory McCann  wrote:

> What about lgbtq=primary (& lgbtq:*=primary) for "this venue is run
> primary for people of the LGBTQ community, or is primarily frequented by
> LGBTQ people"?
>

Yes, I think that would cover it.

Maybe "primarily" would be a (slightly) better word?

Thanks

Graeme
___
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

On Sat, 27 Oct 2018 at 01:01, Tom Pfeifer  wrote:

> On 26.10.2018 16:41, Robert Skedgell wrote:
> > On 26/10/18 11:44, 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.
> >
> > An unmarked crossing may have no road markings or signs, but if there is
> > tactile paving and/or a raised/lowered/flush kerb on the footway
> > (sidewalk), how else would one tag it?
>

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

Any other suggestions?

Thanks

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

Re: [Tagging] Wastewater Plants

2018-10-26 Thread François Lacombe

Hi

That's a good idea, other components of wastewater treatement plants should
be mapped the same way
Nevertheless, man_made isn't appropriate for that.

wastewater=* or at least water=* should be used for such values, shouldn't
you?

All the best

François

Le ven. 26 oct. 2018 à 19:23, Clifford Snow  a
écrit :

> I'd like to expand tagging of wastewater treatment plants by adding in
> clarifiers and digesters to the man_made=wastewater_plant wiki page.
>
> This came about as I was editing an area with a wastewater treatment
> facility. I didn't know what the various parts of the facility were
> called.  A friend who works in GIS for the counties wastewater division
> helped me with the terminology for these objects.
>
> The two objects are
> 1. Clarifiers https://www.dropbox.com/s/k87y9sf144xxylv/clarifier.png?dl=0
> 2. Digesters https://www.dropbox.com/s/q8jxmgvs8heb314/digester.png?dl=0
>
> According to Wikipedia, clarifiers are settlement tanks that continuously
> remove sediment from the wastewater. [1]
>
> Digesters use a process called anaerobic digestion is used to breakdown
> sewage sludge. [2] since anaerobic digester is used in other processes, I'd
> like to keep it simple and just call them digesters.
>
> For tagging, I'd to suggest the two tags.
> man_made=clarifier (used 28 times)
> man_made=digester (anaerobic used 3 times, including one misspelling)
>
>
> I'm not sure if clarifier and digester are what the British call them, if
> someone knows, please let me know.
>
>
> [1] https://en.wikipedia.org/wiki/Clarifier
> [2] https://en.wikipedia.org/wiki/Anaerobic_digestion
>
> Clifford
>
> --
> @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] 2 meaning for crossing=zebra

sent from a phone

> On 26. Oct 2018, at 18:24, SelfishSeahorse  wrote:
> 
> That's true and i agree, but how would you name a tag of a pedestrian
> crossing where pedestrians have right of way (and that doesn't have
> traffic lights) crossing=pedestrian_right_of_way?

for me that’s a crossing=zebra, but this might just be because I’ve never 
mapped in a country with crossings where pedestrians took precedence that were 
not zebra crossings.

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Daniel Koć

W dniu 26.10.2018 o 22:08, Eugene Alvin Villar pisze:
>
> On the other hand. diplomatic offices and services encompass a range
> that is much too narrow such that I don't think having diplomatic=* as
> a primary key seems appropriate. I would prefer if we just have the
> office=diplomatic + diplomatic=* tag combination instead. This nicely
> parallels and complements the office=government + government=* tag
> combination[1] that we already have, but instead applying to foreign
> governments.
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:office=government


It matches nicely, indeed, but on the other hand this is probably not an
office:

https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Dambassadors_residence


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Daniel Koć

W dniu 26.10.2018 o 21:27, Allan Mustard pisze:
>
> Regarding the question of using office=* as the primary key or
> diplomatic=* I note that the Key:diplomatic wiki article admonishes:
>
> Note
> Do not use diplomatic=* without amenity=embassy since it is not
> independently recognised by renderers.
>

I would be happy to render them in OSM Carto (default map style on OSM.org):

1. It makes sense to me and usage of this tag seems to be proper,
however I don't know about the others involved there. Probably someone
needs to make the ticket and discuss subject if needed.

2. Not every diplomatic object is embassy, this seems like good choice
to not tag things for rendering...

Historically the problem is lack of experience with moving to new,
better defined and more rich schemes in OSM Carto (like public_transport
or healthcare). The excuse was a written rule to "prevent unfavorable
fragmentation of tag use" (
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#general-purpose
). My take is that there is also different case ("favorable"
fragmentation), which is a smooth migration, but that was not considered
valid by others, probably to stay neutral and move along only when
tagging habits really do change for good. But for some well known tags I
think this is not helping, since lack of rendering in OSM Carto is not
neutral fact for mappers ("It's an important feedback mechanism for
mappers to validate their edits" from the same sentence, but nobody ever
mentioned it, including me...).

Again: that's what I personally think and others my have different
opinions. Yet if somebody else agrees, it makes sense to discuss it in
our issue tracker:

https://github.com/gravitystorm/openstreetmap-carto/issues


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

office=government
On Sat, Oct 27, 2018 at 2:53 AM Paul Allen  wrote:

> If you can come up with a better value than "diplomatic" then do so.  If
> you don't like it being under
> the office key, maybe have diplomatic=* as the primary key rather than a
> secondary key under
> office (although that may well contravene OSM naming conventions I've
> never heard of).  But if
> we can have healthcare=doctor as an alternative to amenity=doctors or
> office=doctor then I don't see why
> diplomatic=embassy would be a bad idea.
>

In my opinion, having healthcare=* as a primary key makes a lot of sense
because the medical and healthcare profession and services encompasses a
really wide range of "amenities" from doctor's offices where you can visit
for consultations, to dentists, to hospitals with emergency and surgery
facilities, to dialysis centers, to veterinarians, and even to alternative
medical facilities like acupuncture clinics if we really want to go down
that path.

On the other hand. diplomatic offices and services encompass a range that
is much too narrow such that I don't think having diplomatic=* as a primary
key seems appropriate. I would prefer if we just have the office=diplomatic
+ diplomatic=* tag combination instead. This nicely parallels and
complements the office=government + government=* tag combination[1] that we
already have, but instead applying to foreign governments.

[1] https://wiki.openstreetmap.org/wiki/Tag:office=government
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Paul Allen

On Fri, Oct 26, 2018 at 8:28 PM Allan Mustard  wrote:

> Regarding the question of using office=* as the primary key or
> diplomatic=* I note that the Key:diplomatic wiki article admonishes:
>
> Note
> Do not use diplomatic=* without amenity=embassy since it is not
> independently recognised by renderers.
>
> How do we get around that (probably a naive question on my part since I am
> not a programmer)?
>

It is a matter of convincing the programmers that going down this route is
a good idea.  Which
calls for diplomatic skills rather than programming skills.  Do you know
anyone with suitable
qualifications? :)

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

Regarding the question of using office=* as the primary key or
diplomatic=* I note that the Key:diplomatic wiki article admonishes:

Note
Do not use diplomatic=* without amenity=embassy since it is not
independently recognised by renderers.

How do we get around that (probably a naive question on my part since I
am not a programmer)?

On 10/27/2018 12:03 AM, Daniel Koć wrote:
> W dniu 26.10.2018 o 20:52, Paul Allen pisze:
>>
>> If you can come up with a better value than "diplomatic" then do so. 
>> If you don't like it being under
>> the office key, maybe have diplomatic=* as the primary key rather
>> than a secondary key under
>> office (although that may well contravene OSM naming conventions I've
>> never heard of).  But if
>> we can have healthcare=doctor as an alternative to amenity=doctors or
>> office=doctor then I don't see why diplomatic=embassy would be a bad
>> idea.
>
>
> Yes, I also think that we don't have to (over)use amenity or office
> keys. We have diplomatic key spacename already defined and used (2015
> was groundbreaking here), so I would go with that in general:
>
> https://wiki.openstreetmap.org/wiki/Key%3Adiplomatic
>
> https://taginfo.openstreetmap.org/keys/diplomatic#values
>
>
> -- 
> "Excuse me, I have some growing up to do" [P. Gabriel]
>
>
> ___
> 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 - (consulate)

2018-10-26 Thread Daniel Koć

W dniu 26.10.2018 o 20:52, Paul Allen pisze:
>
> If you can come up with a better value than "diplomatic" then do so. 
> If you don't like it being under
> the office key, maybe have diplomatic=* as the primary key rather than
> a secondary key under
> office (although that may well contravene OSM naming conventions I've
> never heard of).  But if
> we can have healthcare=doctor as an alternative to amenity=doctors or
> office=doctor then I don't see why diplomatic=embassy would be a bad idea.


Yes, I also think that we don't have to (over)use amenity or office
keys. We have diplomatic key spacename already defined and used (2015
was groundbreaking here), so I would go with that in general:

https://wiki.openstreetmap.org/wiki/Key%3Adiplomatic

https://taginfo.openstreetmap.org/keys/diplomatic#values


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Paul Allen

On Fri, Oct 26, 2018 at 6:10 PM Allan Mustard  wrote:

a) consulates are not embassies;
>

Indeed.  If they were the same thing they'd have the same name. :)

b) embassies and consulates are government offices, but there is no
> agreement that office=government is appropriate;
>

I suspect that many of us (me, for one) who have not been intimately
involved with diplomatic
missions interpret "government" as meaning the government (national,
provincial or local) of
the specified country.  Yes, technically, embassies are extensions of the
government of the
sending country but they don't feel like government offices to me.  If I
curse the government,
as I frequently do, I'm thinking of my national government not all the
embassies in my country.

c) neither is an amenity;
>

Heartily agreed.

d) office=diplomatic is a reasonable option that while not utterly precise
> is close enough (I don't love it but can live with it), and that in tandem
> with diplomatic=[embassy, consulate, etc.] would meet OSM guidelines?
>

If you can come up with a better value than "diplomatic" then do so.  If
you don't like it being under
the office key, maybe have diplomatic=* as the primary key rather than a
secondary key under
office (although that may well contravene OSM naming conventions I've never
heard of).  But if
we can have healthcare=doctor as an alternative to amenity=doctors or
office=doctor then I don't see why
diplomatic=embassy would be a bad idea.

Also consider diplomatic:service=* or something along those for visas,
etc.  There are probably lots
of things like that (such as help with import licensing) that may or may
not be offered by any
particular mission.  You're the person who knows about these things and
it's better if you cover
all the options now than have people invent them on an ad hoc basis later
and come up with
things that turn out to be sub-optimal.

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

[Tagging] Martitime disputed borders - was "Add some tag to identify disputed borders ?"

2018-10-26 Thread Andy Townsend


On 26/10/2018 18:16, Yuri Astrakhan wrote:

Another related issue -- maritime disputed borders.


Indeed, that is a case where overlapping admin_level=2 boundaries may 
make sense.


Another example is around Gibraltar, where both of the interested 
parties can claim to have some control over the some of the same pieces 
of the area concerned, and it's another place where I don't think what 
we've got in OSM is as good as it could be.


In the case of Gibraltar I'd suggest that a full discussion of the 
current situation is probably in order, and I've suggested the 
"International Boundaries" thread in the OSM forum 
https://forum.openstreetmap.org/viewtopic.php?id=61207 in the past as a 
place for that (see e.g. my comments on 
https://www.openstreetmap.org/changeset/62809907 ).  I used that forum 
as a central place to refer people to during the discussions about the 
Western Sahara issues (see 
https://forum.openstreetmap.org/viewtopic.php?pid=602864#p602864 for the 
start of that).


Best Regards,

Andy


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

[Tagging] Wastewater Plants

2018-10-26 Thread Clifford Snow

I'd like to expand tagging of wastewater treatment plants by adding in
clarifiers and digesters to the man_made=wastewater_plant wiki page.

This came about as I was editing an area with a wastewater treatment
facility. I didn't know what the various parts of the facility were
called.  A friend who works in GIS for the counties wastewater division
helped me with the terminology for these objects.

The two objects are
1. Clarifiers https://www.dropbox.com/s/k87y9sf144xxylv/clarifier.png?dl=0
2. Digesters https://www.dropbox.com/s/q8jxmgvs8heb314/digester.png?dl=0

According to Wikipedia, clarifiers are settlement tanks that continuously
remove sediment from the wastewater. [1]

Digesters use a process called anaerobic digestion is used to breakdown
sewage sludge. [2] since anaerobic digester is used in other processes, I'd
like to keep it simple and just call them digesters.

For tagging, I'd to suggest the two tags.
man_made=clarifier (used 28 times)
man_made=digester (anaerobic used 3 times, including one misspelling)


I'm not sure if clarifier and digester are what the British call them, if
someone knows, please let me know.


[1] https://en.wikipedia.org/wiki/Clarifier
[2] https://en.wikipedia.org/wiki/Anaerobic_digestion

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Add some tag to identify disputed borders ?

2018-10-26 Thread Yuri Astrakhan

Another related issue -- maritime disputed borders. In the case of Crimea,
the disputed border with Russia is over water, thus not showing clearly in
many renderings, and over land with Ukraine, showing as a solid line - thus
appearing to side with the Russian interpretation.

A while ago Paul Norman wrote osmborder tool to help with the disputed and
maritime border rendering [1].  His tool mostly uses disputed=yes . The big
problem with rendering was that multiple borders
(city/county/state/country) were all overlapping one on top of the other,
producing a solid line. Instead, when drawing there should always be just
one line with the lowest admin level.

[1]:  https://github.com/pnorman/osmborder

On Fri, Oct 26, 2018 at 12:05 PM Noémie Lehuby  wrote:

> Hello,
>
> There seems to be no actual consensus on the way to map disputed borders.
> The statement from the Foundation
> 
> recommend to map the border that "best meets realities on the ground" but
> it's not what is actually in our database:
> See for instance :
> https://www.openstreetmap.org/#map=12/45.8481/18.8378
> https://framapic.org/kIvnPSllBtnv/h1J8xti7US1F.gif
> Both borders (according to Croatia vs according to Serbia) are mapped.
>
> The same between Soudan and South Soudan:
> https://framapic.org/lcWCkmek7L7i/icYVenvHzPZs.gif
>
> In some places, there are boundary=disputed or dispute=yes on the boundary
> ways, which is very convenient for a map-maker to know that there is a
> dispute on these border and that you may want to render it with a different
> style (or use another source).
> Should this practice be generalized on all disputed borders or at least
> submitted as a proposal ?
>
> --
> Noémie Lehuby
> Qwant Research
>
> ___
> 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 - (consulate)

2018-10-26 Thread Colin Smale

On 2018-10-26 18:41, Eugene Alvin Villar wrote:

> On Fri, Oct 26, 2018 at 10:27 AM Warin <61sundow...@gmail.com> wrote: 
> 
>> In OSM I would expect the term government not to be a foreign government but 
>> a resident one.
> 
> Uniquely, Italy hosts its own embassy to the Holy See (aka Vatican City). So 
> technically, you could use "government" for that single embassy. ;-)

Indeed, I believe all the embassies to the Holy See are physically in
Rome. I wonder which is the "receiving state", responsible for
accommodation, security etc.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

Colin, et al,

Thanks for this.  You have not misunderstood the doctrine at all, but
you have not quite taken it to its full conclusion.  The examples you
cite involve interaction between the embassy and the outside world
(pizza delivery, lease contracts, employment contracts of local staff,
radio transmitters, and diplomatic vehicles maneuvering on host-country
roads).  Radio (wireless) is specifically covered in the Vienna
Convention because radio waves propagate beyond the boundaries of the
embassy.  That said, if a murder is committed on embassy premises, the
sending side has jurisdiction (in the case of the United States, the
Bureau of Diplomatic Security of the U.S. Department of State).  Once
the lease is signed, the embassy cannot be evicted even if the rental
payment is not paid (for a similar issue see this news item

about a derelict embassy building in Washington, DC).  Once the embassy
chancery is constructed, if the sending side decides to renovate the
interior of the embassy, it is done in accord with sending-side
construction standards, not necessarily host-country standards.  No,
pizza is not considered an export, but it is an item of trivial value
akin to the duty-free bottle of fine single malt Scotch I brought back
from Dubai two weeks ago; however, if I import 1,250 pounds of
consumables via sea freight, they enter the host-country import
statistics.  Regarding personnel, host-country personnel must be hired
and paid in accord with host-country law in most cases, though in many
countries embassies pay in dollars despite host-country laws requiring
payment in local currency and cite extraterritoriality as the legal
grounds for this.  Sending side personnel (like me) are hired, paid, and
fired in accord with sending side rules, period.  And yes, we pay fines,
but we don't pay taxes.  Please note that immunities and
extraterritoriality are defined not only in the Vienna Convention at
this point but also by court precedents established over the past 57
years, which is one reason the Department of State has a large staff of
lawyers.

As to why the .gov top-level domain is used only by government bodies in
the United States, that's because Al Gore DARPA invented the internet
and DARPA is a U.S. institution, so we got first dibs, that's all.  Many
other governments use their two-byte country top-level domain with
either go. or gov. in front of it, e.g., go.jp for the Japanese
government, gov.uk for the UK government, and so on.  In response to
some of the comments, a) no, that doesn't mean the U.S. government is
the only government, and I never said that; b) yes, these gov.xx and
go.xx domains are used for embassies' and consulates' e-mail and
websites, and c) the point I'm trying to make is that embassies and
consulates are government offices, even if not of the host
country--their staff are government employees, their budgets come from a
government somewhere, and their property is government property. 

I believe we are approaching some sort of consensus that amenity=embassy
is not adequate and that something needs to be done to correct this. 
Are we in agreement that

a) consulates are not embassies;
b) embassies and consulates are government offices, but there is no
agreement that office=government is appropriate;
c) neither is an amenity;
d) office=diplomatic is a reasonable option that while not utterly
precise is close enough (I don't love it but can live with it), and that
in tandem with diplomatic=[embassy, consulate, etc.] would meet OSM
guidelines?

We're only five days into the RFC so lots of time left to comment!

cheers,
Allan Mustard
apm-wa

On 10/26/2018 1:28 PM, Colin Smale wrote:
> On 2018-10-26 03:26, Allan Mustard wrote:
>> Under the legal doctrine of extraterritoriality, the embassy or
>> consulate is considered to be located in the sending country for
>> purposes of legal jurisdiction.  Extraterritoriality is virtually
>> unlimited in the case of an embassy; it is more limited in the case
>> of a consulate but still exists 
>
> Allan,
>
> That doesn't sound quite right. As I read the UN conventions, the
> diplomatic staff have some immunities which are linked to their
> personal status and not linked to their being in the embassy
> buildings. The premises themselves are inviolable by the host state,
> which means local laws sometimes cannot actually be enforced without
> invitation from the Ambassador. However, the embassy as a premises is
> still part of the receiving country. Delivering pizza to them is not
> an export. The lease contract is under the laws of the host country.
> Employment contracts for support staff can be under the law of
> the host country. Their radio transmitters need to be licensed by the
> host country. Diplomatic cars have to pay speeding fines and parking
> tickets. But in the case of violations, the only sanction available to
> the host

Re: [Tagging] Feature Proposal - RFC - (consulate)

On Fri, Oct 26, 2018 at 10:27 AM Warin <61sundow...@gmail.com> wrote:

> In OSM I would expect the term government not to be a foreign government
> but a resident one.
>

Uniquely, Italy hosts its own embassy to the Holy See (aka Vatican City).
So technically, you could use "government" for that single embassy. ;-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 2 meaning for crossing=zebra

On Fri, 26 Oct 2018 at 17:13, Martin Koppenhoefer
 wrote:
>
> > On 26. Oct 2018, at 16:39, SelfishSeahorse  
> > wrote:
> >
> > Because road markings at crossings tell pedestrians if they have right
> > of way or not.
>
> it depends on the jurisdiction which kind of markings have which implications 
> or meanings. We’re mostly interested in collecting a model of the meanings, 
> the physical representations are more a kind of source for this information. 
> Nice as an addon, but not essential for the model (but also not useless).

That's true and i agree, but how would you name a tag of a pedestrian
crossing where pedestrians have right of way (and that doesn't have
traffic lights) crossing=pedestrian_right_of_way?

It seems easier to tag what's visible on the ground.

Regards
Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

On Fri, 26 Oct 2018 at 17:09, Martin Koppenhoefer
 wrote:
>
> On 26. Oct 2018, at 16:39, SelfishSeahorse  wrote:
> >
> > Yes, the (yellow) zebra crossings are called 'zebra stripes'
> > (Zebrastreifen) -- or officially 'pedestrian stripes'
> > (Fussgängerstreifen) -- independently if there are traffic lights or
> > not.
>
>
> is a sign required in switzerland [...]

In rural areas a sign [1] is required, in built-up areas it is only
required if the crossing is badly visible.

[1]: 
https://commons.wikimedia.org/wiki/File:CH-Hinweissignal-Standort_eines_Fussgängerstreifens.svg

> [...] and do pedestrian take precedence?

Without traffic lights, pedestrians have always the right of way. With
traffic lights, pedestrians only have right of way when the light is
green.

> Are there additional signs at traffic lights?

No.

Regards
Markus

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

[Tagging] Add some tag to identify disputed borders ?

2018-10-26 Thread Noémie Lehuby


Hello,

There seems to be no actual consensus on the way to map disputed borders.
The statement from the Foundation 
 
recommend to map the border that "best meets realities on the ground" 
but it's not what is actually in our database:

See for instance :
https://www.openstreetmap.org/#map=12/45.8481/18.8378
https://framapic.org/kIvnPSllBtnv/h1J8xti7US1F.gif
Both borders (according to Croatia vs according to Serbia) are mapped.

The same between Soudan and South Soudan: 
https://framapic.org/lcWCkmek7L7i/icYVenvHzPZs.gif


In some places, there are boundary=disputed or dispute=yes on the 
boundary ways, which is very convenient for a map-maker to know that 
there is a dispute on these border and that you may want to render it 
with a different style (or use another source).
Should this practice be generalized on all disputed borders or at least 
submitted as a proposal ?


--
Noémie Lehuby
Qwant Research

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

Re: [Tagging] mast / tower / communication_tower (again)

On Fri, 26 Oct 2018 at 01:58, Greg Troxel  wrote:
>
> This reliance on guys does not align with engineering reality.  guys are
> needed depending on forces/loading, and there can be unguyed masts, that
> are exactly like guyed masts but a bit shorter.

I agree.

> > A tower is a tall, slim free-standing structure, usually with internal
> > access. (Possible include from wiki: "Towers are specifically distinguished
> > from "buildings " in that they are
> > not built to be habitable but to serve other functions.")

Imho, the current definition of man_made=tower -- 'A tower is a
building, which is higher than it is wide' -- is nonsensical. A tower
can be a building (if it has walls and a roof) but it doesn't have to
be a building -- for instance, i wouldn't call an open lookout tower
[1] or the Eiffel Tower [2] buildings.

[1]: https://upload.wikimedia.org/wikipedia/commons/7/78/Gurtenturm.JPG
[2]: https://commons.wikimedia.org/wiki/File:Tour_Eiffel_Wikimedia_Commons.jpg

> For an example of something used in communications (an American thing,
> but totally normal and other countries surely have equivalent things
> with the same characteristics):
>
>   http://www.rohnnet.com/rohn-65g-tower
>
> which says right there can be up to 500 feet when guyed and 80 feet not
> guyed.  But it's the same thing in both cases -- it just needs more
> support when taller where the forces get bigger.

I'd call this is a -- either guyed or not guyed -- mast (because there
is no internal access).

> As I said earlier, things that are maybe 10cm in diameter are usually
> called masts.  These are very minor and not really used in
> telecom/broadcasting.

Do you call this [1] a mast in the USA?

[1]: https://commons.wikimedia.org/wiki/File:LeifersexTimZentrum.jpg

> So maybe we just need
>
>   man_made=antenna_support_structure
>
> for all things which are not buildings and basically exist to support
> antennas, and avoid the tower/mast word choice, which is pretty clearly
> contentious and/or confusing.

I'm not very convinced because that would mean that everything from
this tiny mast on a roof [1] to the Tokyo Tower [2] would be tagged
man_made=antenna_support_structure.

[2]: https://en.wikipedia.org/wiki/Tokyo_Tower

Regards

Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

On Fri, 26 Oct 2018 at 08:23, Martin Koppenhoefer
 wrote:
>
> On the other hand, speaking about “numbers”, those are probably facts and not 
> protectable by copyright

If i'm not mistaken, numbers aren't protected by copyright, but a
compilation of numbers (i.e. a database) can be protected; if not by
copyright then by so-called database right. See:

https://www.esa.int/About_Us/Law_at_ESA/Intellectual_Property_Rights/Copyright_and_databases
https://en.wikipedia.org/wiki/Sui_generis_database_right

Regards

Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

On 26/10/18 16:14, Martin Koppenhoefer wrote:

>> On 26. Oct 2018, at 16:41, Robert Skedgell  wrote:
>>
>> An unmarked crossing may have no road markings or signs, but if there is
>> tactile paving and/or a raised/lowered/flush kerb on the footway
>> (sidewalk), how else would one tag it?
> 
> 
> obstacle=trap

Our local traffic planners are usually more creative when they design
obstacle=trap as a highway "feature".

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

Re: [Tagging] mast / tower / communication_tower (again)

2018-10-26 Thread EthnicFood IsGreat

Date: Thu, 25 Oct 2018 19:57:38 -0400
From: Greg Troxel 
To: Graeme Fitzpatrick 
Cc: OSM Tag 
Subject: Re: [Tagging] mast / tower / communication_tower (again)

Graeme Fitzpatrick  writes:

A mast is a tall, slim structure supported by guys, usually with external
access only

This reliance on guys does not align with engineering reality.  guys are
needed depending on forces/loading, and there can be unguyed masts, that
are exactly like guyed masts but a bit shorter.

A tower is a tall, slim free-standing structure, usually with internal
access. (Possible include from wiki: "Towers are specifically distinguished
from "buildings " in that they are
not built to be habitable but to serve other functions.")

again towers can need guys if they are really tall (300m), even if they
are the same construction that would not need guys if only somewhat tall
(30m).   Guy wires do not make a tower not a tower, in the language of
antenna support structure.

Perhaps this is a UK vs US English thing, or a lay vs radio engineering
thing.  But your definitions (to a US engineering type) seem seriously
wrong.

Now, if you're coming at this from "tower is building that's mostly used
to get something high, and not for inhabitation" and "mast is an
antenna support structure that is not a building.  Note that things that
engineers call towers, such as structures made out of lattice like Rohn
65, are called masts in OSM because they are not buildings"  then I can
see that.  But in that case, there is no requirement for a mast to be
guyed.  I can certainly see a "guyed means not tower" in that world,
because buildings don't have guy wires.

For an example of something used in communications (an American thing,
but totally normal and other countries surely have equivalent things
with the same characteristics):

   http://www.rohnnet.com/rohn-65g-tower

which says right there can be up to 500 feet when guyed and 80 feet not
guyed.  But it's the same thing in both cases -- it just needs more
support when taller where the forces get bigger.

Around me, antenna support structures for cellular (mobile phones) are
typically 30' and I have never seen one guyed.  Some are tube-like
(because planning boards require that) and some are lattice.  But they
are not buildings -- they are antenna support structures that *maybe*
one person could climb inside of, but maybe not.  There are also antenna
support structures for TV, which are typically lattice and 300m tall,
and always guyed.  Everyone calls these towers.   To call the 30m ones
towers because they are not guyed and the 300m ones masts because they
are guyed makes zero sense in US English usage, either for the general
public or for engineers.

As I said earlier, things that are maybe 10cm in diameter are usually
called masts.  These are very minor and not really used in
telecom/broadcasting.

So maybe we just need

   man_made=antenna_support_structure

for all things which are not buildings and basically exist to support
antennas, and avoid the tower/mast word choice, which is pretty clearly
contentious and/or confusing.

Do we need to worry about height for rendering purposes? (which is what
this original discussion started from!) If so, would a simple break-down
into height >30 (m), 30-150, 150+ work?

I don't know why you are proposing classes of height. It seems like
speed limits and road width that we should have a height tag and people
should make their best estimate, and renderers can do what they think
sensible.  Adding some sort of bins for heights in the tagging scheme
seems like unnecessary complexity that brings no value.

+1 to all your points.

Mark

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

[Tagging] lgbtq=primary ? Re: Out of the bars and onto the map: An lgbtq:= tagging scheme?

2018-10-26 Thread Rory McCann


What about lgbtq=primary (& lgbtq:*=primary) for "this venue is run
primary for people of the LGBTQ community, or is primarily frequented by
LGBTQ people"?

lgbtq=majority doesn't cover the aspect of "this venue is run *for*
LGBTQ people" implying it's just a numbers game, and could be applied at
51%+.

There is no clear "opposite" of lgbtq=primary, so this scheme doesn't
have suffer from "lgbtq=yes"'s problem of "How do you tag a non-LGBTQ
venue?" lgbtq=no means it's run by bigots who ban LGBTQ people. Boring
cishet bars can just not have a lgbtq tag.

Thoughts?

On 24/10/2018 20:05, Rory McCann wrote:

On 24/10/2018 09:37, Frederik Ramm wrote:

usually "blah=yes" means that blah is available or blah is permitted,
not that the place is mostly/exclusively for blah. Conversely, in
your definition an "lgbtq=no" would then mean that the place is *not*
specifically an lgbtq place; many users could, however, misread
lgbtq=no (which would be a valid tag for the majority of places since
they don't specifically cater to lgbtq people) as "this place does
not admit lgbtq people" (which is probably/hopefully true only for a
very small number of places).

Good point.

One could say "OSM Tags are for machines, so consult the
docs", but I think tags should be readable to humans (one you learn to
speak OSM-tag-ese).


You don't want "lgbtq=only" since usually an lgbtq bar *will* admit

 > straight people

Yes they will (plus some members of the LGBTQ community are straight, or
in relationship with straight people ). Wiki says diet:vegan=only
means "All *or almost all* products are vegan", so lgbtq=only is
consistent with that, but it seems too confusing, and doesn't read well,
so I think it's not the best.


Perhaps "lgbtq=designated"


That's close, *but* sounds like an official body has designed the place
as a LGBTQ venue, rather than someone choosing to run a business that
way. It could be the best contender.






___
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

On 26/10/18 16:00, Tom Pfeifer wrote:
> On 26.10.2018 16:41, Robert Skedgell wrote:
>> On 26/10/18 11:44, 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.
>>
>> An unmarked crossing may have no road markings or signs, but if there is
>> tactile paving and/or a raised/lowered/flush kerb on the footway
>> (sidewalk), how else would one tag it?
> 
> These are clearly markings for me, the tactile pavings are typically
> white and even visible in aerial imagery. Thus "unmarked crossing" is
> wrong. The tag is tactile_paving=*, used 300k.

In the UK they are pale red on marked crossings (zebra, pelican, toucan,
etc.) and pale yellow at unmarked/uncontrolled crossings. They are not
traffic signs (in the legal sense), they are consequently not designed
to be clearly visible to road users and are only mentioned briefly in
the part of the Highway Code directed at pedestrians (rule 10). I would
say that for any practical purposes, these are unmarked from the
perspective of a road user travelling along the way, but not from the
perspective of a pedestrian crossing the way.

> The question is then, should they be mapped on the road or where they
> are, at the kerb?
> 
> For the lowered kerbs, they should be mapped as lowered kerbs, there is
> a tag for them, kerb=lowered, used 100k.

If they are mapped as kerb=* + tactile_paving=yes at the kerb line, then
there may be a crossing node on the highway as highway=crossing +
crossing=*. At the moment, crossing=unmarked seems to be the least
inappropriate common value here.

-- 
Robert Skedgell (rskedgell)

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

Re: [Tagging] 2 meaning for crossing=zebra



sent from a phone

> On 26. Oct 2018, at 16:41, Robert Skedgell  wrote:
> 
> An unmarked crossing may have no road markings or signs, but if there is
> tactile paving and/or a raised/lowered/flush kerb on the footway
> (sidewalk), how else would one tag it?


obstacle=trap


Cheers, Martin 

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

Re: [Tagging] 2 meaning for crossing=zebra

sent from a phone

> On 26. Oct 2018, at 16:39, SelfishSeahorse  wrote:
> 
> Because road markings at crossings tell pedestrians if they have right
> of way or not.

it depends on the jurisdiction which kind of markings have which implications 
or meanings. We’re mostly interested in collecting a model of the meanings, the 
physical representations are more a kind of source for this information. Nice 
as an addon, but not essential for the model (but also not useless).

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

Re: [Tagging] 2 meaning for crossing=zebra



sent from a phone

> On 26. Oct 2018, at 16:39, SelfishSeahorse  wrote:
> 
> Yes, the (yellow) zebra crossings are called 'zebra stripes'
> (Zebrastreifen) -- or officially 'pedestrian stripes'
> (Fussgängerstreifen) -- independently if there are traffic lights or
> not.


is a sign required in switzerland and do pedestrian take precedence?

Are there additional signs at traffic lights?

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

Re: [Tagging] 2 meaning for crossing=zebra



On 26/10/18 15:39, SelfishSeahorse wrote:
> On Fri, 26 Oct 2018 at 16:14, Martin Koppenhoefer
>  wrote:

>> we generally do not map road markings, we don’t map the divider lines
between lanes, we don’t map diagonally striped areas where traffic can’t
go, we don’t map stop lines, we don’t map any road markings, why’s there
so much focus on the road markings in this thread?
> 
> Because road markings at crossings tell pedestrians if they have right
> of way or not.

Because, at least in the UK, they are legally defined as traffic signs,
failure to comply with which may be a criminal offence.


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

Re: [Tagging] Another multipolygon question

2018-10-26 Thread Kevin Kenny

>
> 26. Oct 2018 11:52 by daveswarth...@gmail.com:
>
> Thanks, That helps a lot. I don't work with routes (yet) but it when I'm
> adding inners to riverbank multipolygons I always add them in the order
> they would appear if you were traveling downstream. It just makes sense to
> me although there's probably no programmatic reason to do it.
>
> On Fri, Oct 26, 2018 at 5:55 AM Mateusz Konieczny 
wrote:
> Order of elements is saved in OSM database.

That appears to be the answer to a different question.

The 'sort' operation in the JOSM relation editor changes the order of the
elements. If the layer is uploaded, the new order of elements, as produced
by the 'sort' operation, will replace the old order in the OSM database.

This is usually what I want with a multipolygon. With a route, I find
myself undoing or further altering a 'sort' operation much more often,
because there are often things about routes that JOSM doesn't get quite
right. (Example - a dual carriageway where both ways end in link elements
looks as if the route has floating endpoints, and the sort operation messes
up one of the directions.) Even there, though, the 'sort' is usually Pretty
Close to right, and is often usable as a starting point. Moreover, I'm not
sure that it can be improved. The topology of a route isn't always quite
right in the field, and some of 'getting it better' amount to 'read the
mapper's mind,' something computers are ordinarily not well equipped to do.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 2 meaning for crossing=zebra

On 26/10/18 14:49, marc marc wrote:
> Le 26. 10. 18 à 10:27, Robert Skedgell a écrit :
>> Do you have any UK examples of zebra crossings with traffic signals?
> 
> https://overpass-turbo.eu/s/D8E
> I dind't have any local knownledge of those but you can see that some 
> mapper repport a zebra ground painting and a traffic light that apply
> to a crossing

Thanks!

I've taken a look at a few of these in Google Street View (which
obviously can't be used as a data source). The ones I have looked at
appear to be tagging errors, which probably should have been tagged as
e.g. crossing=traffic_signals + crossing_ref=pelican / crossing=pelican.

I'll resurvey the 3 nodes nearer to London at some point in the next few
months, when I'm cycling out in that part of Bedfordshire/Hertforshire.

If there were any UK combined traffic signals and zebra crossings, they
would have to be listed as DfT authorisations for non-standard traffic
signs at https://www.dft.gov.uk/traffic-auths/

-- 
Robert Skedgell (rskedgell)

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

Re: [Tagging] 2 meaning for crossing=zebra

Le 26. 10. 18 à 14:57, SelfishSeahorse a écrit :
> How would you tag the absence of traffic signals? crossing=no_traffic_signals?

the most common is crossing=uncontrolled
some mappers find it a bad value (and it is)
but again, imho that need another propal to avoid
an all-in-one too-big-to-be-accepted propal

> And what about the absence of road markings? crossing_ref=unmarked?

some mapper use crossing_ref=unmarked or crossing_ref=none
but imho trying to fix that in the same time 'll fail.

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

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

2018-10-26 Thread Tom Pfeifer


On 26.10.2018 16:41, Robert Skedgell wrote:

On 26/10/18 11:44, 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.


An unmarked crossing may have no road markings or signs, but if there is
tactile paving and/or a raised/lowered/flush kerb on the footway
(sidewalk), how else would one tag it?


These are clearly markings for me, the tactile pavings are typically white and even visible in 
aerial imagery. Thus "unmarked crossing" is wrong. The tag is tactile_paving=*, used 300k.


The question is then, should they be mapped on the road or where they are, at 
the kerb?

For the lowered kerbs, they should be mapped as lowered kerbs, there is a tag for them, 
kerb=lowered, used 100k.


tom

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

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tobias Knerr

On 26.10.2018 11:11, Mateusz Konieczny wrote:
> In general crossing tag is attempting to tag several different things
> at once - for example how I am supposed to tag crossing with island,
> traffic lights and zebra markings in Poland?

The presence of an island is quite commonly tagged as crossing:island=yes.

There's currently no established tagging for a crossing that has both
traffic lights and a zebra pattern, which calls for the invention of a
new tag.

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

[Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tobias Knerr

On 26.10.2018 16:24, Tom Pfeifer wrote:
> Do you see the contradiction? If the crossing is unmarked, the ground
> object already does not provide any guidance. As we map what's on the
> ground, there is nothing to map.

It's not uncommon for a crossing to be physically evident on the ground
(e.g. because of lowered kerbs) even if there are no painted markings.
To me, that would be a typical example of an unmarked crossing.

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

Re: [Tagging] 2 meaning for crossing=zebra

Le 26. 10. 18 à 11:53, Max a écrit :
> In Germany you have either zebra markings or traffic lights, NEVER both.

so some tagging errors in Germany or that exist but you don't known it 
for ex https://www.openstreetmap.org/node/2965700264
With the aerial imagery Ersi, I see the zebra and a pole...
maybe a traffic light for the crossing
the same with this one https://www.openstreetmap.org/node/2051961031

:)

but of course maybe I'm fully wrong with those 2 cases.
but that doesn't solve the issue for several other country :)

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

Re: [Tagging] 2 meaning for crossing=zebra

On 26/10/18 11:44, Tom Pfeifer wrote:
> On 26.10.2018 09:28, SelfishSeahorse wrote:
>> What about tagging the presence or absence of traffic signals with a
>> subkey, e.g. crossing:traffic_signals=yes/no?
> 
> Why should we invent a new subtagging scheme when we already have one
> with crossing=* + crossing_ref=* ?
> 
> On Fri, 26 Oct 2018 at 01:19, Bryan Housel  wrote:
>> - `crossing=unmarked` which is labeled “Unmarked Crossing”
> 
> 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.

An unmarked crossing may have no road markings or signs, but if there is
tactile paving and/or a raised/lowered/flush kerb on the footway
(sidewalk), how else would one tag it?

> Otherwise I would need to set a node every meter on the road, tagging it
> "unmarked crossing" because I can cross the road everywhere.
> 
> And I hate it when the satnav announces a warning for the upcoming
> crossing, and there comes nothing the requires extra attention.

-- 
Robert Skedgell (rskedgell)


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

Re: [Tagging] 2 meaning for crossing=zebra

On Fri, 26 Oct 2018 at 16:14, Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> > On 26. Oct 2018, at 14:57, SelfishSeahorse  
> > wrote:
> >
> > And what about the absence of road markings? crossing_ref=unmarked?
>
>
> we generally do not map road markings, we don’t map the divider lines between 
> lanes, we don’t map diagonally striped areas where traffic can’t go, we don’t 
> map stop lines, we don’t map any road markings, why’s there so much focus on 
> the road markings in this thread?

Because road markings at crossings tell pedestrians if they have right
of way or not.

>
> The interesting information (IMHO) is whether there are traffic lights or 
> not, where the crossings without signals are and whether crossing pedestrians 
> take precedence over vehicles. The actual signs and markings for this are 
> kind of a sideshow for the traffic sign nerds, important to know for the 
> jurisdictions where you map, but nothing that must necessarily be explicitly 
> mapped. We are interested in the effects, aren’t we?

Agree.

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

Re: [Tagging] 2 meaning for crossing=zebra

On Fri, 26 Oct 2018 at 16:17, Martin Koppenhoefer
 wrote:
>
> in Switzerland? In Italy they aren’t called zebra crossings (despite the 
> markings), they’re called traffic lights with pedestrian crossing. A zebra 
> crossing here means there aren’t traffic lights.

Yes, the (yellow) zebra crossings are called 'zebra stripes'
(Zebrastreifen) -- or officially 'pedestrian stripes'
(Fussgängerstreifen) -- independently if there are traffic lights or
not.

Regards

Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

sent from a phone

> On 26. Oct 2018, at 16:22, Tobias Knerr  wrote:
> 
> There already is a perfectly fine value for marked crosswalks, which is
> called "uncontrolled".

it unfortunately isn’t perfectly fine, it is completely self contradicting, 
because markings are a kind of control. It is counterintuitive and I subscribe 
to the anecdotal findings Bryan has reported: not knowing about anything osm, 
someone will usually think uncontrolled means unmarked.

Then again, I also support you and others in telling Bryan to wait a bit before 
introducing the next competing alternative via editor presets.

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

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tom Pfeifer

On 26.10.2018 15:37, Bryan Housel wrote:

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.

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.

Do you see the contradiction? If the crossing is unmarked, the ground object already does not
provide any guidance. As we map what's on the ground, there is nothing to map.

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.

It's not about empathy, it's about psychology. If you hear the same warning at each and every
corner, again and again, you stop listening, and eventually switch it off.

The warning is useful when it comes only in situations that are different, such as a marked crossing
where the pedestrian has priority, and often exercises it without watching or very suddenly.

tom

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

Re: [Tagging] 2 meaning for crossing=zebra

sent from a phone

> On 26. Oct 2018, at 15:37, Bryan Housel  wrote:
> 
> 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.

how would this be verifiable? If there are no signs and marks, will mappers 
have to produce statistics about places where people cross, and possibly how 
many incidents there are?

I acknowledge the American situation is very different to the European because 
over here there’s no concept like jaywalking, so for Europe I must agree with 
Tom: without any markings and signs it seems arbitrary where to put crossing 
possibilities.

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

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tobias Knerr

On 26.10.2018 01:18, Bryan Housel wrote:
> 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” 

There already is a perfectly fine value for marked crosswalks, which is
called "uncontrolled". Replacing this with the barely-used "marked" (100
times fewer uses than "uncontrolled") seems unhelpful. After all, the
issue that gave rise to the "zebra" value isn't to distinguish marked
from unmarked crossings. It's to distinguish two different types of
marked-but-uncontrolled crossings.

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

Re: [Tagging] highway=crossing used on ways

2018-10-26 Thread André Pirard


On 2018-10-13 11:22, Mateusz Konieczny wrote:
12. Oct 2018 09:25 by gpetermann_muenc...@hotmail.com 
:


In November 2015 I fix nearly all such ways, since then the number
increased again to 488. I don't know about iD, but JOSM prints a
warning
when you use this tagging, still many edits were made with JOSM. I
wonder if that means that we should accept highway=crossing as a
shortcut for highway=footway + footway=crossing?

I once opened a thread saying that the term "crossing" is contradictory 
with "passage pour piétons".
The English term restrictively suggests being perpendicular to the road 
and is tagged on a node.
The French concept covers zebras that are drawn on & along -- e.g. half 
of -- the road, is tagged on the highway on which the passage runs, and 
they do exist. Unanswered problem: how to tag which side of the road the 
paint is on.
That feature meaning a place where pedestrians can walk safely, even a 
full area applies.


The answers were typical of "tagging for the renderer", e.g. disguising 
sidewalks as being on the road.


How do we tag that without being "fixed"?

All the best,

André.


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

Re: [Tagging] 2 meaning for crossing=zebra

sent from a phone

> On 26. Oct 2018, at 15:15, SelfishSeahorse  wrote:
> 
> Because there are countries where pedestrian crossings with traffic
> signals also have zebra markings and it's not obvious that
> crossing=zebra excludes crossings with traffic signals (they are even
> called zebra crossings too).

in Switzerland? In Italy they aren’t called zebra crossings (despite the 
markings), they’re called traffic lights with pedestrian crossing. A zebra 
crossing here means there aren’t traffic lights. 

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

Re: [Tagging] 2 meaning for crossing=zebra

sent from a phone

> On 26. Oct 2018, at 14:57, SelfishSeahorse  wrote:
> 
> And what about the absence of road markings? crossing_ref=unmarked?

we generally do not map road markings, we don’t map the divider lines between 
lanes, we don’t map diagonally striped areas where traffic can’t go, we don’t 
map stop lines, we don’t map any road markings, why’s there so much focus on 
the road markings in this thread? 

The interesting information (IMHO) is whether there are traffic lights or not, 
where the crossings without signals are and whether crossing pedestrians take 
precedence over vehicles. The actual signs and markings for this are kind of a 
sideshow for the traffic sign nerds, important to know for the jurisdictions 
where you map, but nothing that must necessarily be explicitly mapped. We are 
interested in the effects, aren’t we?

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

Re: [Tagging] 2 meaning for crossing=zebra



sent from a phone

> On 26. Oct 2018, at 12:26, Volker Schmidt  wrote:
> 
> Re: precedence of vertical signalling over horizontal signalling
> I am not sure about this here in Italy and even less so in other countries.


I’m not sure for Italy either but I’m sure for Germany, there is a hierarchy 
policeman - traffic lights- vertical signs - horizontal signs/road markings 


> We do have here many crossings that consist only of painted zebra stripes on 
> the ground without any vertical sign.


yes, but these aren’t zebra crossings according to the cds, do you agree?
(unless in proximity to a road crossing)

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

Re: [Tagging] 2 meaning for crossing=zebra

On Fri, 26 Oct 2018 at 15:29, Bryan Housel  wrote:
>
> `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.

Unfortunately crossing=marked doesn't make a difference compared to
crossing=zebra. It's still not possible to tag a marked (zebra)
crossing with traffic signals (except from
crossing=marked;traffic_signals, which data users possibly can't
handle).

And if it's intended that crossing=marked excludes marked crossings
with traffic signals, it isn't unambiguous any more.

Regards

Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

Le 26. 10. 18 à 10:27, Robert Skedgell a écrit :
> Do you have any UK examples of zebra crossings with traffic signals?

https://overpass-turbo.eu/s/D8E
I dind't have any local knownledge of those but you can see that some 
mapper repport a zebra ground painting and a traffic light that apply
to a crossing
___
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

On Fri, 26 Oct 2018 at 12:53, Jyri-Petteri Paloposki
 wrote:
>
> On 26.10.2018 10.44, SelfishSeahorse wrote:
> > There are some marked non-zebra crossings in Switzerland:
> >
> > https://www.mapillary.com/map/im/zMqUsiFYNMiJ3_kA4ODHSQ
> > https://www.mapillary.com/map/im/OVsXNBwnJXFIAobJxFjUlQ
> >
> > However, i'm unsure if vehicles have to stop there if pedestrians want
> > to cross. (Vehicles have to stop at the yellow 'zebra' crossings.)
>
> In Finland the marking in the first image is for an ”extension of a
> cycleway”, ie. a place for cyclists to cross the road. It's not meant
> for foot traffic and doesn't give cyclists precedence over traffic on
> the road, unlike a marked footway crossing.

There's a cycleway that ends about 50 m next to that road markings.
Maybe it has been painted at the wrong place. :-) (It's not uncommon
that road markings or signs are misplaced or illogical. My favourite
is this sign [1] places some metres in front of stairs.)

[1]: 
https://commons.wikimedia.org/wiki/File:CH-Hinweissignal-Sackgasse_mit_Ausnahmen.svg

>
> The second one would in Finland probably be used for marking the edges
> of a bump, also having no effect on the precedence of traffic modes.

Thanks for your explanations. Could be that the authorities intended
that car drivers slow down by pretending that there is a speed table
(kind of a visual speed table).

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

They end in gov.tm, and UK government domains end in gov.uk.  UK embassy 
employees abroad have addresses ending in fco.gov.uk 

Sent from my iPhone

> On Oct 26, 2018, at 11:11 AM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> sent from a phone
> 
>> On 26. Oct 2018, at 05:14, Allan Mustard  wrote:
>> 
>> My official email address ends in .gov :-).
> 
> 
> what kind of proofs Warin’s point, because .gov is for US government domains 
> while you are not in the US.
> 
> Turkmen government domains don’t end with.gov, or do they?
> 
> 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] 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

On Fri, 26 Oct 2018 at 12:46, Tom Pfeifer  wrote:
>
> Why should we invent a new subtagging scheme when we already have one with 
> crossing=* + crossing_ref=* ?

Because there are countries where pedestrian crossings with traffic
signals also have zebra markings and it's not obvious that
crossing=zebra excludes crossings with traffic signals (they are even
called zebra crossings too). Therefore these crossings often get
wrongly tagged crossing=zebra.

Besides, the meaning of crossing=uncontrolled is even less clear.

> On Fri, 26 Oct 2018 at 01:19, Bryan Housel  wrote:
>  > - `crossing=unmarked` which is labeled “Unmarked Crossing”
>
> 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.

The absence of a highway=crossing (and a crossing=*) tag on a node
shared by a road and a footway doesn't mean that there is an unmarked
crossing, it could also mean that the footway continues on the
sidewalk or that the pedestrian crossing hasn't been mapped yet.

Regards

Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

On Fri, 26 Oct 2018 at 12:37, marc marc  wrote:
>
> Le 26. 10. 18 à 09:28, SelfishSeahorse a écrit :
> > What about tagging the presence or absence of traffic signals with a
> > subkey, e.g. crossing:traffic_signals=yes/no?
>
> it is indeed always possible to take out all the values to make
> them keys.
> but if iD only enters the marking in crossing_ref like the other
> editors, the crossing key will again indicate whether or not there is a
> light. so is it useful to change the name of the key there too?

How would you tag the absence of traffic signals? crossing=no_traffic_signals?

And what about the absence of road markings? crossing_ref=unmarked?

> experience shows that if you want to change everything, in the end
> nothing changes because many contributors have started from immobility
> when the solution is too large. that is why I think it is useful to
> focus on how to correctly inform the type of ground marking

If we can solve the problem with less change that's fine too, but the
solution should be unambiguous and clear.

Regards

Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

2018-10-26 Thread François Lacombe

Hi Lionel,

Thank you for this clarification
I agree on classification, let's talk about tagging

Le ven. 26 oct. 2018 à 11:30, Lionel Giard  a
écrit :

>
> And as a sub-type (indicating type of construction) : we got the "lattice
> pylon", "tubular pylon", "lattice mast", "tubular mast" or just "tubes"
> (for antennas isolated). So it would correspond to the t
> *ower:construction=guyed_lattice* or *guyed_tube* (for mast) and* lattice*
> or *freestanding *(for the tower). Note that the older concrete telecom
> tower is noted as "tubular pylon".
>
> => And thus, the only change i would make is to the sub-tag
> *tower:construction* : using "*lattice*" or "*tube*" for the
> "freestanding" towers (the freestanding value is more general but give not
> much information as if it is not guyed, i think it is always freestanding).
> So at the end, the engineering definition is clearly indicated via this
> tag.
>

structure={lattice,guyed, tube...} would be better than tower:construction.
15k uses vs 150k.
Lattice is the structure and have nothing to do with actual construction.
This tag should be avoided.


> Thus, as i see it, the *tower *tag is the equivalent of pylon (as in the
> power=* tag where the power=tower is the equivalent of what we call
> "electricity pylon" here) and the *mast *are either the guy-wired
> structures OR the "largest" structures on the roof of buildings (which are
> clearly not an unique antenna). And then we need a tag for isolated *antenna
> *(i saw that a "telecom=antenna" was proposed on the telecom wiki page
> and i used it some times, but that's just a tag to indicate either on a
> node (on top of a building) or on another structure (like power=tower) that
> a telecom antenna is there. So to me, this covers everything i see in our
> database.
>

telecom=antenna would be a device, wile we are discussion of supports.
It's the same for power=transformers (a device) supported by a power=pole
(a support). Using power=* for both support and device cause small issues
because power=* is used for the support.

telecom=antenna may be used to tag individual antennas on large towers too.

All th best

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

[Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Jyri-Petteri Paloposki

On 26.10.2018 13.26, Volker Schmidt wrote:
> Re: marking= zebra
> Problem is that the zebra stripes can have different meaning in
> different countries. In Italy it can mean, depending on the context:
> "foot-only" or "foot-and-bicycle". In addition we also have additional
> non-zebra signing for bicycles.
> It would be much better to distinguish between "marked" and "unmarked"
> for the horizontal signalling, without specifying the signalling details
> and use foot=yes|no and bicycle=yes|no|dismount (?) to indicate the type
> of traffic that can cross.
> 
> Re: precedence of vertical signalling over horizontal signalling
> I am not sure about this here in Italy and even less so in other countries.
> We do have here many crossings that consist only of painted zebra
> stripes on the ground without any vertical sign.
> 
> Re: Zebra markings with traffic lights
> This standard in Italy.
> In Germany the standard for that looks different: two rows of dashed
> white stripes (may we should call that Okapi), but the meaning is the same.

Aaaand here's Finland, just to mix things up :)

In Finland crossings controlled with traffic lights often (if not
always) have also a vertical signal and zebra markings, which are only
in effect if the traffic lights are off for some reason.

A footway crossing that gives foot traffic precedence is marked with a
vertical signal and MAY be marked with a zebra marking. Both are usually
used, but not always, and a missing zebra marking doesn't have any
effect on the meaning of the controls.

There's another kind of marking, which is kind of a ”cut” zebra marking
(like this: https://www.finlex.fi/data/sdliite/liikm/5818.gif ). This
may be on the side of a zebra marking or by itself, and it designates a
bicycle and moped crossing. The bicycle crossing has no effect on
precedence of the traffic modes.

Best regards,
-- 
Jyri-Petteri Paloposki

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

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Jyri-Petteri Paloposki

On 26.10.2018 10.44, SelfishSeahorse wrote:
> There are some marked non-zebra crossings in Switzerland:
> 
> https://www.mapillary.com/map/im/zMqUsiFYNMiJ3_kA4ODHSQ
> https://www.mapillary.com/map/im/OVsXNBwnJXFIAobJxFjUlQ
> 
> However, i'm unsure if vehicles have to stop there if pedestrians want
> to cross. (Vehicles have to stop at the yellow 'zebra' crossings.)

In Finland the marking in the first image is for an ”extension of a
cycleway”, ie. a place for cyclists to cross the road. It's not meant
for foot traffic and doesn't give cyclists precedence over traffic on
the road, unlike a marked footway crossing.

The second one would in Finland probably be used for marking the edges
of a bump, also having no effect on the precedence of traffic modes.

Best regards,
-- 
Jyri-Petteri Paloposki

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

Re: [Tagging] 2 meaning for crossing=zebra

Le 26. 10. 18 à 09:41, Martin Koppenhoefer a écrit :
> traffic light controlled crossings also have zebra markings.

so a crossing with a zebra ground marking (as a armchair mapper may 
create) must not be mapped with crossing=zebra :)
It's the need to move ground marking out of the crossing=* key
to get back one key for traffic light and another key for ground marking
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tom Pfeifer


On 26.10.2018 09:28, SelfishSeahorse wrote:

What about tagging the presence or absence of traffic signals with a
subkey, e.g. crossing:traffic_signals=yes/no?


Why should we invent a new subtagging scheme when we already have one with 
crossing=* + crossing_ref=* ?

On Fri, 26 Oct 2018 at 01:19, Bryan Housel  wrote:
> - `crossing=unmarked` which is labeled “Unmarked Crossing”

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.


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


tom

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

Re: [Tagging] 2 meaning for crossing=zebra

Le 26. 10. 18 à 09:28, SelfishSeahorse a écrit :
> What about tagging the presence or absence of traffic signals with a
> subkey, e.g. crossing:traffic_signals=yes/no?

it is indeed always possible to take out all the values to make
them keys.
but if iD only enters the marking in crossing_ref like the other 
editors, the crossing key will again indicate whether or not there is a 
light. so is it useful to change the name of the key there too?
experience shows that if you want to change everything, in the end 
nothing changes because many contributors have started from immobility 
when the solution is too large. that is why I think it is useful to 
focus on how to correctly inform the type of ground marking

> I've already proposed to replace crossing=island with
> crossing:island=yes [1] for the same reason, that is, because when
> using crossing=island, it's not possible to specify if the pedestrian
> crossing is marked or not.
> [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/Key:crossing:island

It's a good idea (and I like that the propal focus on one tag/issue
in order to hope that this will facilitate its adoption
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 2 meaning for crossing=zebra

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
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 :)

Without wishing to draw too hasty a conclusion from this discussion,
a coherent scheme would be to have :
crossing with the usual current meaning (traffic lights or not)
crossing_ref with the type of marking (this key might need a better 
name, but I know that osm is very reluctant to change historically
bad names...)
It is then enough for the preset to ask:
marking on the ground or not ? fill corssing_ref
protected by traffic lights or not ? fill crossing

if a armchair mapper ignore if the crossing is protected by traffic 
lights or not, don't fill the crossing key.
that 'll allow other mapper to see that the info is not filled and they 
may act in stead of guessing (is marked used to tell that no traffic 
lights exist ou that's it's unknown ?)

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

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Volker Schmidt

Re: marking= zebra
Problem is that the zebra stripes can have different meaning in different
countries. In Italy it can mean, depending on the context: "foot-only" or
"foot-and-bicycle". In addition we also have additional non-zebra signing
for bicycles.
It would be much better to distinguish between "marked" and "unmarked" for
the horizontal signalling, without specifying the signalling details and
use foot=yes|no and bicycle=yes|no|dismount (?) to indicate the type of
traffic that can cross.

Re: precedence of vertical signalling over horizontal signalling
I am not sure about this here in Italy and even less so in other countries.
We do have here many crossings that consist only of painted zebra stripes
on the ground without any vertical sign.

Re: Zebra markings with traffic lights
This standard in Italy.
In Germany the standard for that looks different: two rows of dashed white
stripes (may we should call that Okapi), but the meaning is the same.

On Fri, 26 Oct 2018 at 11:35, Martin Koppenhoefer 
wrote:

> Am Fr., 26. Okt. 2018 um 11:30 Uhr schrieb Mateusz Konieczny <
> matkoni...@tutanota.com>:
>
>> Am Fr., 26. Okt. 2018 um 11:12 Uhr schrieb Mateusz Konieczny <
>> matkoni...@tutanota.com>:
>>
>> In general crossing tag is attempting to tag several different things
>>>
>>> at once - for example how I am supposed to tag crossing with island,
>>>
>>> traffic lights and zebra markings in Poland?
>>>
>>
>>
>> in the simplest case (dual carriageway connected with traffic lights),
>> you could tag them like this:
>>
>> footway connecting the dual carriageway.
>>
>> start and end node:
>> highway=crossing
>> crossing=traffic_signals
>>
>>
>> Not on nodes shared by road and footway?
>>
>
>
> it is the same (see the assumption above). If sidewalks are mapped, the
> better description would indeed have been intersection of road with
> sidewalk.
>
>
>>
>>
>> on the way:
>> highway=footway
>> footway=crossing
>> crossing=traffic_island
>>
>>
>> Tagging way crossing=traffic_island and nodes crossing=traffic_signals is
>>
>> deeply not obvious.
>>
>
> as I wrote, you could limit this to the part on the island.
>
> 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] 2 meaning for crossing=zebra



On 26/10/18 10:27, Martin Koppenhoefer wrote:
> Am Fr., 26. Okt. 2018 um 11:21 Uhr schrieb Robert Skedgell
> mailto:r...@hubris.org.uk>>:
> 
> 
> I wonder if it's possible differentiate between a normal traffic signal
> controlled crossing, an uncontrolled zebra crossing and the type of
> crossing you describe using appropriate values of traffic_sign=* ? 
> 
> 
> 
> maybe, generally I would prefer to distinguish between vertical traffic
> signs and road markings in our tagging, as the former take precendence
> over markings.

I did say I risked being parochial in my assumptions :-)

In the UK road markings are also traffic signs and an upright sign does
not necessarily take precedence. For example, the give way transverse
road marking (= = = = =) is required whether the red inverted triangle
upright sign is present or not. Failure to comply with either is an offence.

> Often there are also other signs on traffic signal controlled
> intersections, like stop or give way signs, which only go into effect in
> the case of the traffic lights turned off (common situation in Germany).
> Maybe someone is interested in finding a solution for these as well, or
> maybe it already exists?

More of a headache than I imagined.

-- 
Robert Skedgell (rskedgell)


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

Re: [Tagging] 2 meaning for crossing=zebra

On Fri, 26 Oct 2018 at 11:30, Mateusz Konieczny  wrote:
>
> Tagging way crossing=traffic_island and nodes crossing=traffic_signals is
> deeply not obvious.

+1. That's too complicated. Furthermore it doesn't work on
one-carriageway roads like e.g. here:

https://www.openstreetmap.org/node/893451214

Regards
Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

On Fri, 26 Oct 2018 at 11:12, Mateusz Konieczny  wrote:
>
> Yes. For example in Poland there are crossing markings that look
> very similar and have the same name with different legal
> implications.

Is there more than one marked crossings type w/o traffic signals in
Poland? That is, one where pedestrians have right of way and another
where vehicles have right of way?

Regards
Markus

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

Re: [Tagging] Another multipolygon question

Order of elements is saved in OSM database.


26. Oct 2018 11:52 by daveswarth...@gmail.com :


> Thanks, That helps a lot. I don't work with routes (yet) but it when I'm 
> adding inners to riverbank multipolygons I always add them in the order they 
> would appear if you were traveling downstream. It just makes sense to me 
> although there's probably no programmatic reason to do it.
> Do you know if the sorting operation actually renumber the way-segments, or 
> just displays them in order in the Relation Editor?
> On Fri, Oct 26, 2018 at 10:42 AM Kevin Kenny <> kevin.b.ke...@gmail.com 
> > > wrote:
>
>> On Thu, Oct 25, 2018 at 10:40 PM Dave Swarthout <>> daveswarth...@gmail.com 
>> >> > wrote:
>>
>>> Thanks again, Adam.
>>> That was also helpful. It brings up a question about sorting. After 
>>> sorting, are the elements arranged according to their coordinates, that is 
>>> to say, spatially? Or nearest node at each end of a member way is checked 
>>> to see which other node ways are closest? Or what?
>>>
>>
>> It's a little complicated.  The gist is that 'sort' tries to hook as much 
>> together as possible so that the ways are in 'the right order'.
>> It starts by making the longest chains possible by putting the ways with 
>> common endpoints together.
>> Once that's done, I *think* that it greedlly starts with the longest open 
>> chain and drops that in place. Then it successively finds the nearest 
>> endpoint on another open chain and starts from there, so that the gaps are 
>> as short as possible. This may not be the best choice, particularly if the 
>> relation is really messed up, but at least it connects what it can, and if 
>> you zoom to the disconnected ways, you can eyeball where you want them to go.
>> Routes are slightly more complicated, but once you learn to read the column 
>> with the arrows in the relation editor, you'll pretty quickly be able to 
>> figure out what's going on.  in that column, the arrows join if the ways 
>> share an endpoint, and the arrowhead points in the direction of the way. If 
>> the ways form a closed ring, the arrows will, too. In a multipolygon, if all 
>> the ways don't form closed rings after sorting, there's a problem. 
>
>
> -- 
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at > http://dswarthout.blogspot.com 
> ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Johnparis

Thanks for refocusing the discussion, Martin.

I think the new tag should be amenity=diplomatic.

A major reason is the instance where both an embassy and a consulate share
a node. If the new tag is amenity=consulate, you would either need two
nodes in the case where they share a space, which is acceptable but not
ideal, or else a single node with amenity=embassy;consulate, which as I
understand it is on the verge of forbidden.

Another advantage of amenity=diplomatic as the new tag is that it would be
clear that anything tagged "amenity=embassy" has not switched over to the
new model, making quality control easier. If the new tag is
amenity=consulate, it would be unclear whether a consulate tagged as
"amenity=embassy" has been switched to the new model, making quality
control more difficult.

Whatever we agree upon, the new tagging structure won't get into general
use unless (a) it's a preset in ID, and (b) it's rendered in the standard
map.

John

On Fri, Oct 26, 2018 at 10:44 AM Martin Koppenhoefer 
wrote:

> Am Fr., 26. Okt. 2018 um 08:38 Uhr schrieb Graeme Fitzpatrick <
> graemefi...@gmail.com>:
>
>> On Fri, 26 Oct 2018 at 16:12, Martin Koppenhoefer 
>> wrote:
>>
>>> what kind of proofs Warin’s point, because .gov is for US government
>>> domains while you are not in the US.
>>>
>> But for a counter example :-):
>>
>> Australian Embassy in Paris
>>
>>- Embassy Emails:
>>   - General questions : info.pa...@dfat.gov.au
>>   - Consular and passport questions: consular.pa...@dfat.gov.au
>>
>>
>
> it is not a counter example, it is the same situation: australian embassy
> in France using an australian government domain.
>
> FWIW, I don't have strong feelings about the landuse value to apply, but I
> do not believe we should use _only_ landuse to define any kind of _feature_
> (and embassies and consulates are "features" in my reading).
> So regardless of the landuse value that applies or not, we should resolve
> the question how to tag 1 consulate or 1 embassy.
>
> Even if we have not yet found agreement on consulates, it seems we do
> agree that the "diplomatic" key can be useful in this context.
>
> Question is whether we would want to introduce a new amenity=diplomatic
> tag as general tag or if we keep amenity=embassy and introduce
> amenity=consulate (which still would leave room for a diplomatic key for
> subclasses and which still would let us add more detail about provided
> services etc. with other related tags).
>
> Is there someone who believes we should stick to the current scheme and
> keep consulates as a subclass of amenity=embassy, although they are not
> embassies?
>
> 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] 2 meaning for crossing=zebra

2018-10-26 Thread Max


On 26.10.18 11:27, Martin Koppenhoefer wrote:
Often there are also other signs on traffic signal controlled 
intersections, like stop or give way signs, which only go into effect in 
the case of the traffic lights turned off (common situation in Germany). 
Just to clarify: In Germany you have either zebra markings or traffic 
lights, NEVER both. Zebra marking means that road traffic has to stop 
for pedestrians at any time.
I've seen in Spain that zebra markings were removed for crossings with 
traffic lights, so maybe this is becoming more of a standard in other 
places too.


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

Re: [Tagging] Another multipolygon question

2018-10-26 Thread Dave Swarthout

Thanks, That helps a lot. I don't work with routes (yet) but it when I'm
adding inners to riverbank multipolygons I always add them in the order
they would appear if you were traveling downstream. It just makes sense to
me although there's probably no programmatic reason to do it.

Do you know if the sorting operation actually renumber the way-segments, or
just displays them in order in the Relation Editor?

On Fri, Oct 26, 2018 at 10:42 AM Kevin Kenny 
wrote:

> On Thu, Oct 25, 2018 at 10:40 PM Dave Swarthout 
> wrote:
>
>> Thanks again, Adam.
>>
>> That was also helpful. It brings up a question about sorting. After
>> sorting, are the elements arranged according to their coordinates, that is
>> to say, spatially? Or nearest node at each end of a member way is checked
>> to see which other node ways are closest? Or what?
>>
>
> It's a little complicated.  The gist is that 'sort' tries to hook as much
> together as possible so that the ways are in 'the right order'.
>
> It starts by making the longest chains possible by putting the ways with
> common endpoints together.
>
> Once that's done, I *think* that it greedlly starts with the longest open
> chain and drops that in place. Then it successively finds the nearest
> endpoint on another open chain and starts from there, so that the gaps are
> as short as possible. This may not be the best choice, particularly if the
> relation is really messed up, but at least it connects what it can, and if
> you zoom to the disconnected ways, you can eyeball where you want them to
> go.
>
> Routes are slightly more complicated, but once you learn to read the
> column with the arrows in the relation editor, you'll pretty quickly be
> able to figure out what's going on.  in that column, the arrows join if the
> ways share an endpoint, and the arrowhead points in the direction of the
> way. If the ways form a closed ring, the arrows will, too. In a
> multipolygon, if all the ways don't form closed rings after sorting,
> there's a problem.
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 2 meaning for crossing=zebra

Am Fr., 26. Okt. 2018 um 11:30 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

> Am Fr., 26. Okt. 2018 um 11:12 Uhr schrieb Mateusz Konieczny <
> matkoni...@tutanota.com>:
>
> In general crossing tag is attempting to tag several different things
>>
>> at once - for example how I am supposed to tag crossing with island,
>>
>> traffic lights and zebra markings in Poland?
>>
>
>
> in the simplest case (dual carriageway connected with traffic lights), you
> could tag them like this:
>
> footway connecting the dual carriageway.
>
> start and end node:
> highway=crossing
> crossing=traffic_signals
>
>
> Not on nodes shared by road and footway?
>


it is the same (see the assumption above). If sidewalks are mapped, the
better description would indeed have been intersection of road with
sidewalk.


>
>
> on the way:
> highway=footway
> footway=crossing
> crossing=traffic_island
>
>
> Tagging way crossing=traffic_island and nodes crossing=traffic_signals is
>
> deeply not obvious.
>

as I wrote, you could limit this to the part on the island.

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

Re: [Tagging] Radio telescopes

Yes, Arecibo message is not turning Arecibo Observatory into tower:communication
And there is https://en.wikipedia.org/wiki/Radar_astronomy 
 

"Radar astronomy differs from radio astronomy in that the latter is a passive 
observation and 
the former an active one."
but it is also not a communication.

25. Oct 2018 12:04 by joseph.eisenb...@gmail.com 
:


> Please don’t tag radio telescopes with tower:communication. Telescopes 
> observe, they do not communicate or send information.
> On Thu, Oct 25, 2018 at 6:53 PM Andrew Harvey <> andrew.harv...@gmail.com 
> > > wrote:
>
>> What about
>>
>> man_made=tower
>> tower:type=communication
>> tower:construction=dish
>>
>> See for example >> https://www.openstreetmap.org/node/14565 
>> >>  it's even
>> rendered on the default OSM map.
>> On Thu, 25 Oct 2018 at 17:38, Joseph Eisenberg
>> <>> joseph.eisenb...@gmail.com >> > wrote:
>> >
>> > I am working on rendering man_made=telescopes, starting with 
>> > telescope:type=radio. Next will be telescope:type=optical.
>> >
>> > I noticed that man_made=radio_telecope is listed as a possible tagging 
>> > mistake on the telescope wiki page. But there are still over 200 tagged 
>> > with this, versus 450 with telescope:type=radio. It is not on the 
>> > deprecated features page.
>> >
>> > Would it be acceptable to add man_made=radio_telescope to deprecated 
>> > features, and suggest use of the more common man_made=telescope & 
>> > telescope:type=radio tags?
>> > ___
>> > 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] mast / tower / communication_tower (again)

2018-10-26 Thread Lionel Giard

At my work (a telecom company in Belgium), i see these types of mobile
structure construction :
- *Self-supported pylons* (the "*tower*", mostly looking like the
power=tower in OSM, but also including the (older) self-supported tower in
concrete) ;
- *Guy-wired pylons* (the "*mast*" as described in the engineering
definition where it is a structure held by guys);
- *Self-supported roof structure* (half of them are just simple *antennas*,
the other half are *mast *(the larger structure that clearly hold more than
1 antenna on top of buildings));
- *Guy-wired roof structure* (all of them are *mast*);
- And some other things like on electricity pylons(all of them are just
antennas on top of something as far as i know).

And as a sub-type (indicating type of construction) : we got the "lattice
pylon", "tubular pylon", "lattice mast", "tubular mast" or just "tubes"
(for antennas isolated). So it would correspond to the t
*ower:construction=guyed_lattice* or *guyed_tube* (for mast) and* lattice*
or *freestanding *(for the tower). Note that the older concrete telecom
tower is noted as "tubular pylon".

Thus, as i see it, the *tower *tag is the equivalent of pylon (as in the
power=* tag where the power=tower is the equivalent of what we call
"electricity pylon" here) and the *mast *are either the guy-wired
structures OR the "largest" structures on the roof of buildings (which are
clearly not an unique antenna). And then we need a tag for isolated *antenna
*(i saw that a "telecom=antenna" was proposed on the telecom wiki page and
i used it some times, but that's just a tag to indicate either on a node
(on top of a building) or on another structure (like power=tower) that a
telecom antenna is there. So to me, this covers everything i see in our
database.

If we use the current definition, the only problem i see is for the
"self-supported pylons" which should all be tagged as tower (on engineering
terminology), but could currently be tagged as mast if they don't look like
"big tower". But the problem is minor, as if you look at the tag
"tower:construction", the "guyed_lattice" and "guyed_tube" already say that
it is a 'mast' in the engineering definition (and as far as i know, all
masts are either guyed_lattice or guyed_tube construction !). ;-)

=> And thus, the only change i would make is to the sub-tag
*tower:construction* : using "*lattice*" or "*tube*" for the "freestanding"
towers (the freestanding value is more general but give not much
information as if it is not guyed, i think it is always freestanding). So
at the end, the engineering definition is clearly indicated via this tag.

Best regards,
Lionel

Le ven. 26 oct. 2018 à 09:07, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> On 26. Oct 2018, at 01:57, Greg Troxel  wrote:
>
> for all things which are not buildings and basically exist to support
> antennas, and avoid the tower/mast word choice, which is pretty clearly
> contentious and/or confusing.
>
>
>
> what about this:
> https://upload.wikimedia.org/wikipedia/commons/1/11/Killesberg_Tower.jpg
>
> Actual tagging is even more weird, or does anyone recognize a mansard roof
> here?
> https://www.openstreetmap.org/way/306362151
>
> this is not a building, neither by the German nor by the English
> definition, but at least for Germans it is a tower.
> I would not require for towers to be a building (which at a minimum should
> provide some enclosed space).
>
>
> 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] 2 meaning for crossing=zebra

> A traffic light controlled crossing is not a zebra crossing, even if it has 
> zebra markings (also here they do have zebra markings)



And it may be root of problem. In Poland "zebra" is synonym of  "marked 
pedestrian crossing" - 
seehttps://pl.wikipedia.org/wiki/Przej%C5%9Bcie_dla_pieszych 

No amount of documentation will protect from mappers using crossing=zebra.
Maybe crossing=united_kingdom_zebra would work.

markings=zebra is much better as mappers will be less likely to misinterpret 
(thoughthere may be other pitfalls).

26. Oct 2018 11:22 by dieterdre...@gmail.com :


>
>
> Am Fr., 26. Okt. 2018 um 11:12 Uhr schrieb Mateusz Konieczny <> 
> matkoni...@tutanota.com > >:
>
>>   
>> In general crossing tag is attempting to tag several different things 
>>
>>
>> at once - for example how I am supposed to tag crossing with island,
>>
>> traffic lights and zebra markings in Poland?
>>
>
>
> in the simplest case (dual carriageway connected with traffic lights), you 
> could tag them like this:
> footway connecting the dual carriageway.
> start and end node:> highway=crossing> crossing=traffic_signals




Not on nodes shared by road and footway? 


 

> on the way:> highway=footway> footway=crossing> crossing=traffic_island




Tagging way crossing=traffic_island and nodes crossing=traffic_signals is

deeply not obvious.


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

Re: [Tagging] 2 meaning for crossing=zebra

Am Fr., 26. Okt. 2018 um 11:21 Uhr schrieb Robert Skedgell <
r...@hubris.org.uk>:

>
> I wonder if it's possible differentiate between a normal traffic signal
> controlled crossing, an uncontrolled zebra crossing and the type of
> crossing you describe using appropriate values of traffic_sign=* ?



maybe, generally I would prefer to distinguish between vertical traffic
signs and road markings in our tagging, as the former take precendence over
markings.
Often there are also other signs on traffic signal controlled
intersections, like stop or give way signs, which only go into effect in
the case of the traffic lights turned off (common situation in Germany).
Maybe someone is interested in finding a solution for these as well, or
maybe it already exists?

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

Re: [Tagging] 2 meaning for crossing=zebra

Am Fr., 26. Okt. 2018 um 11:12 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

> In general crossing tag is attempting to tag several different things
>
> at once - for example how I am supposed to tag crossing with island,
>
> traffic lights and zebra markings in Poland?
>


in the simplest case (dual carriageway connected with traffic lights), you
could tag them like this:

footway connecting the dual carriageway.

start and end node:
highway=crossing
crossing=traffic_signals

on the way:
highway=footway
footway=crossing
crossing=traffic_island

(for micromapping you might even split the footway, so that the traffic
island part is only above the island)


While I would tag the kind of crossing, I would not usually tag the kind of
road markings, but you could use any tag to do so, like
marking=zebra

A traffic light controlled crossing is not a zebra crossing, even if it has
zebra markings (also here they do have zebra markings).

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

Re: [Tagging] 2 meaning for crossing=zebra

On 26/10/18 09:34, Martin Koppenhoefer wrote:
> Am Fr., 26. Okt. 2018 um 10:28 Uhr schrieb Robert Skedgell
> mailto:r...@hubris.org.uk>>:
> 
> At a zebra crossing, vehicles must give precedence to pedestrians on the
> crossing. No traffic signals are necessary to stop traffic in order for
> pedestrians to cross.
> 
> It may be the case that there are zebra crossings very close to a
> junction with traffic lights, but these are really separate entities and
> should be mapped as such.
> 
> I believe the main reason for using zebra markings at traffic signal
> controlled crossings in some places is that they will give precedence to
> pedestrians even when the lights are turned off.
> 

Thanks, Martin, that's a case which I wasn't aware of. Luckily for me,
it isn't one which can occur here in the UK. (See
http://www.legislation.gov.uk/uksi/2016/362/schedule/14/made )

I wonder if it's possible differentiate between a normal traffic signal
controlled crossing, an uncontrolled zebra crossing and the type of
crossing you describe using appropriate values of traffic_sign=* ? I'm
making the possibly parochial assumption that traffic signals and road
markings are considered to be traffic signs in the jurisdictions concerned.

-- 
Robert Skedgell (rskedgell)

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

26. Oct 2018 03:26 by al...@mustard.net :


> 
> Embassies andconsulates are definitely government facilities/offices. 
>  Underthe legal doctrine of extraterritoriality, the embassy or   
>  consulate is considered to be located in the sending country for
> purposes of legal jurisdiction. 
>
>




[citation needed] - AFAIK this is a myth caused by fact that de facto there is 
no way for host

country to efficiently prosecute but "diplomatic missions do not generally 
enjoy full extraterritorial

 status" - https://en.wikipedia.org/wiki/Extraterritoriality#Current_examples 


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

Re: [Tagging] 2 meaning for crossing=zebra

25. Oct 2018 23:39 by marc_marc_...@hotmail.com 
:


> so my request is : how to avoid again a multi-meaning tag ?




Create multiple tags and do not attempt to create shortcut again.




In general crossing tag is attempting to tag several different things 


at once - for example how I am supposed to tag crossing with island,

traffic lights and zebra markings in Poland?

 


> may/must we separate the type of crossing from the ground marking ?
>




Yes. For example in Poland there are crossing markings that look

very similar and have the same name with different legal 


implications.




People in that situation will use crossing=zebra, no matter what was

original intention of fist uers and what is documented on wiki

as the intended meaning,


 


> it doesn't scare me to propose a mass edition once a coherent scheme
> has been found. 




Note that it is unfixable with mass edit. Resurvey of everything is basically 
needed.


And it is one more reason for people caring about this information to fix it as

soon as possible.

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

Re: [Tagging] mast / tower / communication_tower (again)

Untrue. See https://wiki.openstreetmap.org/wiki/Wikidata#Importing_data 

A significant part of Wikidata data was harvested from Wikipedia, in which for 
example most 
coordinates are produced using/copied from products with licenses conflicting 
with OSM.
For example copying from Google Maps to OpenStreetMap (even indirectly) is not 
OK, and copying 
Wikidata coordinates (that were copied to Wikipedia from Google Maps) is also 
not OK. Note that 
Wikipedia allows and encourages to use Google Maps to obtain coordinate data 
and other sources 
that are not OK to be used in OSM.
http://en.wikipedia.org/wiki/Wikipedia:Obtaining_geographic_coordinates#Google_Maps

http://en.wikipedia.org/wiki/Wikipedia:Obtaining_geographic_coordinates#From_printed_maps

26. Oct 2018 00:50 by joseph.eisenb...@gmail.com 
:

> Wikidata’s license is CC0, so that is compatible, and almost all numerical 
> values from Wikipedia, like height of buildings and towers, are also in 
> Wikidata.
> On Fri, Oct 26, 2018 at 7:05 AM Graeme Fitzpatrick <> graemefi...@gmail.com 
> > > wrote:
>
>>
>>
>> On Thu, 25 Oct 2018 at 19:27, Martin Koppenhoefer <>> dieterdre...@gmail.com 
>> >> > wrote:
>>
>>> Looking closely, many/most towers might be seen as "multi purpose" (radio 
>>> AND tv?), 
>>
>> Which would both count as communication
>> 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] 2 meaning for crossing=zebra