date:20181026

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

Re: [Tagging] 2 meaning for crossing=zebra

On Thu, 25 Oct 2018 at 23:40, marc marc  wrote:
>
> Hello,
>
> I have a big issue with crossing=zebra.
> it prevent to fill in the other value for crossing like
> crossing=traffic_signals crossing=uncontrolled
> the wiki [1] said that crossing=zebra is a shortchut for
> crossing=uncontrolled + crossing_ref=zebra in the UK
> but a lot of zebra also in UK and outside UK have traffic_signals
> and must be tagged with crossing=traffic_signals
> so at the end, crossing=zebra has no meaning... maybe the previous
> contributor mean crossing=uncontrolled + crossing_ref=zebra
> but maybe he mean only crossing_ref=zebra
> I fix a few week a lot of crossing=zebra crossing_1=traffic_signals
> or crossing=zebra;traffic_signals that show it's an issue.

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

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

Regards
Markus

___
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 00:55 Uhr schrieb marc marc <
marc_marc_...@hotmail.com>:

> But "iD issue" is "load the aerial imagery, look for a zebra"
> select a node, search for crossing, select "crossing(zebra)"
> iD add highway=crossing crossing=zebra. upload the changeset.
>


it may work in some places, but where I map you cannot see the kind of
crossing from aerial imagery, because traffic light controlled crossings
also have zebra markings.




> iD never ask you if you known that no traffic light exist.
> so it may be an alias for crossing=uncontrolled
>


The term uncontrolled always bothered my as ill chosen, as it literally
means no traffic control, while traffic control means policemen, traffic
lights, traffic signs, road markings, i.e. the term is used against its
natural meaning.


It's why a just to move "the ground marking is a zebra" out
> the crossing key.
>


"crossing" is not about ground markings, but about the typology of the
crossing. Ground markings may play a role, but they are not required
(generally).



> With crossing_ref as currently described on the wiki,
> a mapper can fill "the ground marking is a zebra" without
> any "try to guesss if it's uncontrolled or not-filled" "meaning".
>


you can do this is you want, personally I am not interested in the kind of
markings, I only want to know what kind of crossing it is. A "zebra
crossing" for me is a crossing with zebra markings and no traffic lights
and zebra crossing traffic signs if away from a road crossing (Italian
legal definition). I.e. the road markings alone don't define a zebra
crossing (unless it is in proximity to a road crossing), vertical signs are
required.

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 00:02, Martin Koppenhoefer
 wrote:
>
> I agree that in areas where marked pedestrian crossings aren’t marked as 
> zebra crossings, the tag could create problems or could not apply (I do not 
> know about such places but someone wrote it in the wiki).

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

___
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 01:19, 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”

If crossing=marked would exclude marked crossings with traffic
signals, that wouldn't solve the problem that Marc and i often come
across. If people see a marked crossing on the aerial imagery, they
would tag it crossing=marked, which would imply that this crossing
doesn't have traffic signals.

The problem with the crossing=* key is that it combines several
incompatible concepts, that is the presence or absence of traffic
signals, of road markings and of islands. It seems that the only
solution to this problem is moving all these properties to dedicated
subkeys, that is:

crossing:traffic_signals=yes/no
crossing:marked=yes/no
crossing:island=yes/no

Regards
Markus

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

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

2018-10-26 Thread Warin


On 26/10/18 17:37, Graeme Fitzpatrick wrote:


On Fri, 26 Oct 2018 at 16:12, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> 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:

 o


General questions : info.pa...@dfat.gov.au


 o


Consular and passport questions:
consular.pa...@dfat.gov.au


DFAT by the way is the Australian Dept of Foreign Affairs & Trade



And the uk government uses *.gov.uk , The Japanese use *.go.jp, the 
French use *.gouv.fr


I am certain there are many more examples of this.


And these email addresses and domains are used both locally and 
internationally.


However in OSM landuse=government does not imply US government everywhere!


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

Re: [Tagging] 2 meaning for crossing=zebra



On 25/10/18 22:39, marc marc wrote:
> Hello,
> 
> I have a big issue with crossing=zebra.
> it prevent to fill in the other value for crossing like 
> crossing=traffic_signals crossing=uncontrolled
> the wiki [1] said that crossing=zebra is a shortchut for 
> crossing=uncontrolled + crossing_ref=zebra in the UK
> but a lot of zebra also in UK and outside UK have traffic_signals
> and must be tagged with crossing=traffic_signals
> so at the end, crossing=zebra has no meaning... maybe the previous 
> contributor mean crossing=uncontrolled + crossing_ref=zebra
> but maybe he mean only crossing_ref=zebra
> I fix a few week a lot of crossing=zebra crossing_1=traffic_signals
> or crossing=zebra;traffic_signals that show it's an issue.

Do you have any UK examples of zebra crossings with traffic signals?
From my understanding of UK traffic signs (which include road markings
and signals), this seems rather unlikely.

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.

> a issue was closed in iD [2] some time ago because "the dev dislike 
> crossing_ref" (it is in fact a very ugly name for the tag)
> right now josm [3] is changing preset to drop cossing_ref=zebra
> in favor of crossing=zebra

I agree with the ugliness of crossing_ref=zebra. NOw the wiki has been
updated, I can happily get rid of it in all my edits.
> 
> I am part of a group of a group of mappers working on accessibility
> are planning to open a talk to fix it but the news of the commit flow 
> preceded us
> 
> so my request is : how to avoid again a multi-meaning tag ?
> 
> may/must we separate the type of crossing from the ground marking ?
> in short : move away crossing=zebra in another tag ? if yes
> is crossing_Re so ugly than in the same time another tag need
> to be used for the ground marking ?
> 
> let's avoid the argument of "there are too many cases to fix",
> it doesn't scare me to propose a mass edition once a coherent scheme
> has been found. but having half tools that fill a value with another 
> meaning than other or historical meaning is a big issue for the use
> of the data.
> 
> [1] https://wiki.openstreetmap.org/wiki/Key:crossing
> [2] https://github.com/openstreetmap/iD/issues/4788
> [3] https://josm.openstreetmap.de/ticket/16793
> 
> Regards,
> Marc
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

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

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

2018-10-26 Thread Colin Smale

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 country is basically
withdrawal of recognition of diplomatic staff. 

Have I misunderstood your interpretation of "extraterritoriality"? 

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

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

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

Re: [Tagging] 2 meaning for crossing=zebra

Am Fr., 26. Okt. 2018 um 10:28 Uhr schrieb Robert Skedgell <
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.

Cheers,
Martin
___
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

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] 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

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] 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

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] 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] 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] 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] 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

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] 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] 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] 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] 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 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

26. Oct 2018 11:55 by selfishseaho...@gmail.com 
:

> On Fri, 26 Oct 2018 at 11:12, Mateusz Konieczny <> matkoni...@tutanota.com 
> > > 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?
>

AFAIK no. Maybe there are some edge cases with marked bicycle crossings 
withoutaccompanying pedestrians crossings and not marked as forbidden for 
pedestrians.
___
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

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

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

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

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

[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] 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

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] 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

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] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Allan Mustard

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

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] 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

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

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



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

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 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] 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

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] 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

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

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

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

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

[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

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] 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

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

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] 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 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] 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

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

[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] 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

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)

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] 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

[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] 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

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] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Eugene Alvin Villar

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] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Allan Mustard

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 country

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] 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

[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

[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

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

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 Allan Mustard

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

2018-10-26 Thread Eugene Alvin Villar

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

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] 2 meaning for crossing=zebra