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

[Graeme Fitzpatrick]

On Tue, 13 Nov 2018 at 10:58, marc marc  wrote:

> everybody agree with that, the question was : how ?


Hopefully, the drawing works?

Not sure if this will make any sort of sense, but here goes!

[image: OSM dispute.jpg]
Countries A & B share a common border, stretching from Country C to the
Ocean (& wouldn't it make for much easier mapping if things did look like
this!). Both countries are happy with the top & bottom sections of the
border (solid, straight lines). The old border continued as the straight,
dashed line. Country A has now decided that the border should follow the
line of the river that curves 50klm into "B" (curved dashed line).

So, the borders (solid lines) would already be marked as
boundary=administrative + admin_level=2

How about marking the disputed area (dashed lines) as a new level, say
boundary=administrative + admin_level=15?

That could also then be rendered as a dashed red line on the map, & maybe
even show the whole area between these as a red cross-hash or similar, to
warn mappers that this area is in dispute, so be careful with how things
are marked.

Conceivable?

Thanks

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

Re: [Tagging] [Talk-us] Population during mandatory evacuations

[Greg Troxel]

Minh Nguyen  writes:

> (Crossposted to the talk-us and tagging lists.)
>
> Due to the ongoing Camp Fire in Northern California [1], the place POI
> for the town of Paradise got tagged with population=0 before the
> change was reverted. Following some discussion about this changeset in
> OSMUS Slack [2], I started a discussion on the wiki about preferring
> more stable population figures over supposition about temporary
> circumstances. [3]

That's really unreasonable that somebody would do that.

Obviously population is the number of people whose residence is in a
place, or something like that, not how many people are there this
minute.

It does get tricky for communities that have year-rounders and summer
people, where "residence" is blurry.  But everybody leaving for a week
does not change the population, just as people showing up for a parade
for 6 hours does not etiher.

On top of that, the idea that it's 0, between emergency people and
non-compliant people, does not in general seem credible, and if the
person making the edit was not actually there and able to judge this,
they're out of line on that basis too.


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

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Warin]

What I am suggesting;

Stage 1 - Vote on office=diplomatic as a replacement for amenity=embassy

Once that is past
Stage 2 - vote on diplomatic=embassy/consulate/?
with embassy=embassy/high_commission/?
consulate=consulate/consulate_general/?
?=?/?

Stage 3 .. if you have further things.

That way each vote is on one issue only not the lot bundled together.


Once that is past On 13/11/18 12:22, Allan Mustard wrote:


Warin, may I please remind you that in your message of 31 October you 
were the mapper who expressed great concern about loss of data?


On 11/13/2018 2:37 AM, Colin Smale wrote:


On 2018-11-12 22:00, Warin wrote:


On 13/11/18 01:07, Allan Mustard wrote:
Not contrived at all in these days of tight budgets. I see no 
reason the inverse would not work. I'll add it.


I think there are too many things in the proposal. Keep it simple. 
Yes the 'extras' might sound nice but they add complexity and each 
one is a point that can lead to someone objecting to that specific 
thing and leading to enough no votes that it fails.


At moments like this I like to invoke one of my heroes: Albert 
Einstein. One famous saying attributed to him is: As simple as 
possible, but no simpler.


If you simplify complex realities too much, you lose valuable detail. 
If it's complex, it's complex. If you want to leave out a level of 
detail, such as being able to distinguish between the different types 
of services provided on behalf of multiple "tenant" countries in a 
diplomatic mission, then so be it, but let's discuss whether it is 
desirable to leave that out, and whether the resultant ambiguity is 
acceptable. Data modelling means constructing an approximation to 
reality, and is all about what details to keep in and what to leave 
out. Once it is left out, it cannot be reconstructed from the rest of 
the data. (If it can, your data model is not properly normalised.)


If OSM is being limited to being suboptimal because of politics and 
the inability to reach consensus, I would rather the system was fixed 
instead of condemning the whole business to eternal mediocrity.





___
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)-->(office=diplomatic)

[Allan Mustard]

Warin, may I please remind you that in your message of 31 October you
were the mapper who expressed great concern about loss of data?

On 11/13/2018 2:37 AM, Colin Smale wrote:
>
> On 2018-11-12 22:00, Warin wrote:
>
>> On 13/11/18 01:07, Allan Mustard wrote:
>>> Not contrived at all in these days of tight budgets. I see no reason
>>> the inverse would not work. I'll add it.
>>
>> I think there are too many things in the proposal. Keep it simple.
>> Yes the 'extras' might sound nice but they add complexity and each
>> one is a point that can lead to someone objecting to that specific
>> thing and leading to enough no votes that it fails.
>
> At moments like this I like to invoke one of my heroes: Albert
> Einstein. One famous saying attributed to him is: As simple as
> possible, but no simpler.
>
> If you simplify complex realities too much, you lose valuable detail.
> If it's complex, it's complex. If you want to leave out a level of
> detail, such as being able to distinguish between the different types
> of services provided on behalf of multiple "tenant" countries in a
> diplomatic mission, then so be it, but let's discuss whether it is
> desirable to leave that out, and whether the resultant ambiguity is
> acceptable. Data modelling means constructing an approximation to
> reality, and is all about what details to keep in and what to leave
> out. Once it is left out, it cannot be reconstructed from the rest of
> the data. (If it can, your data model is not properly normalised.)
>
> If OSM is being limited to being suboptimal because of politics and
> the inability to reach consensus, I would rather the system was fixed
> instead of condemning the whole business to eternal mediocrity.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[marc marc]

On 12. Nov 2018, at 15:34, Simon Poole  wrote:
> a consistent set of border polygons 
> (which is what people want in the end).

everybody agree with that, the question was : how ?
i didn't understand very well what you propose to achieve this goal
take one of the initial exemple.
the border IS inconsistent at the moment and I didn't understand
what the concrete solution you're thinking about.
split the disputed area in 2 and use this way as a unique "border"
in the relationship between the 2 countries? why not...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Eugene Alvin Villar]

On Mon, Nov 12, 2018 at 9:23 PM Noémie Lehuby  wrote:

> Should we consider the dispusted=yes tag on boundary ways as a *de facto*
> standard and uniformize a few borders ? Should we create a proposal about
> this tag ?
>
> The borders data do not fit the doc and the statement from the Foundation
> and are not really usable right now...
>

My thinking on this is we should re-purpose the relation roles for this
sort of tagging. Right now we just copy the roles from type=multipolygon
relations (inner, outer) when we should be using something like the
following:

Hypothetical but real-life example:
Country A and Country B are disputing Territory C but currently Country A
controls it.
- The borders (ways) between A and B that are not in dispute should be
tagged with role=de_jure in both countries' boundary relations
- The line of control (so the border between B and C) should be tagged with
role=de_facto in both countries' boundary relations.
- The claimed border of B (so the "border" between A and C) should be
tagged with role=claimed in Country B's relation.

So if you want to draw borders as we currently draw them in OSM, just
pick-up the de_jure and de_facto role ways in the relations to build up the
boundary polygons.

But if you're from Country B and you want your claimed borders, just
pick-up the de_jure and claimed role ways in the relations to build up
Country B's boundary polygon.

The point is, "inner" and "outer" are really superfluous and can be
inferred from the geometry itself. So we should be using the relation role
to tag these sorts of things. And we can even use it to tag even more
complicated situations like if Territory C is split in control between A
and B.

I am open to alternatives to my suggested role names, by the way
("de_jure", "de_facto", "claimed").
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 12. Nov 2018, at 15:34, Simon Poole  wrote:
> 
> There are only a very small number of countries, maybe none, that don't
> have any sections of their borders that are disputed. While it can be
> argued that moving away from our de facto area of control model allows
> to reflect reality better, it also makes the borders essentially
> unusable without making ~200 x "average number of border disputes"
> decisions to get to a consistent set of border polygons (which is what
> people want in the end).



maybe that part could be simplified if we could find a way to tag who 
recognizes or supports which version, so you could render the world according 
to the swiss government (for example)? I am not sure though if all countries 
have opinions on border disputes far away from them. From a practical point of 
view, if we had one tag for each supporting country these hundreds tags would 
get in the way for finding the other tags, a semicolon separated list with 
country codes is risking of going beyond the 255 char limit, and would not be 
very nice to edit. 

I clearly subscribe to your reality argument, international recognition is an 
important aspect of borders, apart from the physical control.

Most people don’t need a „consistent set of border polygons“, it wouldn’t hurt 
them to see 2 alternatives for (generally/often) relatively small patches of 
land. Probably most people do not care for the whole world, a few decisions for 
the places near them will usually be sufficient for rendering their area of 
interest according to their preferred view - assuming they do not want to see 
the disputes, which I am not even certain of.
You can get easy to use, simplified country shapefiles from natural earth, if 
you want OSM, it is because you care for detail :) 
Getting a consistent set of country borders including all known disputed 
borders is something we should render possible, it can also reduce the 
suspicion we would be mostly transporting a western view of the world, and 
effectively lead to more neutrality. A consistent set _should_ have the 
disputes.


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

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Colin Smale]

On 2018-11-12 22:00, Warin wrote:

> On 13/11/18 01:07, Allan Mustard wrote: 
> 
>> Not contrived at all in these days of tight budgets. I see no reason the 
>> inverse would not work. I'll add it.
> 
> I think there are too many things in the proposal. Keep it simple. Yes the 
> 'extras' might sound nice but they add complexity and each one is a point 
> that can lead to someone objecting to that specific thing and leading to 
> enough no votes that it fails.

At moments like this I like to invoke one of my heroes: Albert Einstein.
One famous saying attributed to him is: As simple as possible, but no
simpler. 

If you simplify complex realities too much, you lose valuable detail. If
it's complex, it's complex. If you want to leave out a level of detail,
such as being able to distinguish between the different types of
services provided on behalf of multiple "tenant" countries in a
diplomatic mission, then so be it, but let's discuss whether it is
desirable to leave that out, and whether the resultant ambiguity is
acceptable. Data modelling means constructing an approximation to
reality, and is all about what details to keep in and what to leave out.
Once it is left out, it cannot be reconstructed from the rest of the
data. (If it can, your data model is not properly normalised.) 

If OSM is being limited to being suboptimal because of politics and the
inability to reach consensus, I would rather the system was fixed
instead of condemning the whole business to eternal mediocrity.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Warin]

On 13/11/18 01:07, Allan Mustard wrote:
Not contrived at all in these days of tight budgets. I see no reason 
the inverse would not work. I’ll add it.


I think there are too many things in the proposal. Keep it simple. Yes 
the 'extras' might sound nice but they add complexity and each one is a 
point that can lead to someone objecting to that specific thing and 
leading to enough no votes that it fails.


Make the proposal on office=diplomatic only and it should pass.

Then, if you want pursue the other items individually. Personally I 
don't like lumping things together and then separating them at a lower 
level when it was separated before - I refer to the diplomatic=* tag 
that is in use now compared to the proposed diplomatic=embassy(includes 
high commission etc)/consulate (includes consulate general)/and some 
other thing that I don't recall.





Sent from my iPhone

On Nov 12, 2018, at 12:31 PM, Colin Smale > wrote:



On 2018-11-11 21:51, Graeme Fitzpatrick wrote:

Just for the sake of asking a theoretical question that I know would 
probably never appear in real life :-)
Would / could you also use the multi-letter codes as you show eg 
NATO, WTO, SEATO?
& a mixture of them, so the British Ambassador to Belgium, who is 
also the delegate / representative to NATO (if there is such a 
thing?), would be

country=GB
target=BE;NATO
It's possible I guess to have the inverse of that as well, where the 
embassy of e.g. France also houses the ambassador of e.g. Monaco, 
both being accredited to the same receiving nation? (contrived example)
If a mission "represents" multiple countries, and the services 
offered are different, how could that be tagged? Something like the 
full Embassy of A also housing consular services for B.
Possibly two OSM objects, one for the embassy of A and a separate 
node for the services on behalf of B?

___
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] Reversible Road tagging

[Richard]

On Sun, Nov 11, 2018 at 07:59:41PM -0600, Paul Johnson wrote:
> lanes=* should be the total number of lanes... if it's a one-lane road with
> two way traffic, I'd go with...

things change somewhat when using lanes:forward:conditional and 
lanes:backward:conditional - these are not likely to sum up to
a constant total number of lanes.

But thinking more about it reversible freeways can definitely not 
be modeled using lanes alone. 
oneway:conditional and oneway=reversible would be the cleaner
solution.

> On Sun, Nov 11, 2018 at 4:01 PM Richard  wrote:
> 
> > On Sun, Nov 11, 2018 at 12:27:57AM -0600, Paul Johnson wrote:
> > > Are we talking a 1 lane or a 3 lane road?  Because that looks like it's
> > > describing a 3 lane road.
> >
> > looks like 1 lane to me but the example would not work for other reasons.
> >
> > We could do
> >
> > lanes=0
> >   # this is "default" for routers/apps which don't undrestand/use
> > conditional
> >   # restrictions
> > lanes:forward:conditional=2 @ (09:00-17:00)
> > lanes:backward:conditional=2 @ (17:01-8:59)
> >   # the version for apps which do understand them
> >
> > However, I am afraid that "lanes=0" won't stop most routers sending cars
> > that
> > way, other kind of restriction is needed here.
> >
> > That could be
> > access=no
> > access=yes @ (09:00-17:00); yes @ (17:01-8:59)
> >  # this two lines are needed to sort out routers/apps which don't
> >  # undrestand/use conditional
> > oneway:conditional= yes  @ (09:00-17:00); -1 @ (17:01-8:59)
> >
> > In principle
> > oneway=reversible
> > oneway:conditional= yes  @ (09:00-17:00); -1 @ (17:01-8:59)
> >
> > would be a much more elegant solution but again, I am afraid that
> > oneway=reversible isnt widespread enough to be known by most routers.
> >
> > I have just added that as hypothetical example to
> > https://wiki.openstreetmap.org/wiki/Tag:oneway%3Dreversible
> >
> > The lane number could be added on top of that  - and would be very
> > confusing if it were variable because there would be backward/forward
> > lanes on top of reversible oneway..

Richard

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

Re: [Tagging] Estimated values for height

[bkil]

Actually, accuracy=* is used quite a few times by itself:

https://taginfo.openstreetmap.org/search?q=accuracy

It is common to combine tokens in such a way in the key grammar of OSM.

When I map objects that may be worthy as a navigation aid, like a survey
point or a milestone, I usually specify a large value if I've only taken
measurements with an imprecise smartphone, so others with millimeter GPS
can improve it later on if they will.

I only add this tag for objects that matter, ie., not on every bush or
waste basket. I assume by default that everything is imprecise unless
tagged with accuracy<1.

If you don't know the accuracy, (and you wouldn't prefer to estimate the
accuracy of the estimate itself...), I think some kind of source tag may
work. However, I can see how changeset metadata is more efficient and I
usually prefer that when possible.

Although, it would be nice if we had better tools to show such metadata
while editing. For example, Josm could offer to download a given area with
history as well. It could then annotate each tag in the properties window
with the last modification date, source and comment. That would help
finding deleted objects as well, along with attribution and history
tracking for objects that went through various steps of merging or
splitting.

On Mon, Nov 12, 2018 at 11:38 AM Sergio Manzi  wrote:

> ... because, as you correctly point out, comments are just a
> human-to-human thing (*let's put AI aside for the moment...*), while a
> structured information for accuracy could open the way to an automated
> method to "*update this information only if the accuracy of this new
> measure is better than the old one*".
> On 2018-11-12 11:30, Warin wrote:
>
> I think the only people who are going to see those indications of accuracy
> are other mappers.
> In which case .. why not use a note, a comment ...human to human.
> There is no need to complicate it with rigid computer organised 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

Re: [Tagging] tagging for an office of the local representative to parliament

[Allan Mustard]

Even for a government bureaucrat like me it seems a bit wordy. :-)

On 11/12/2018 6:19 PM, Martin Koppenhoefer wrote
>> On 7. Nov 2018, at 02:28, Graeme Fitzpatrick  wrote:
>>
>> Maybe change the title a little bit: "office of an elected official"?
> maybe this goes too far?
>
> Cheers, Martin 
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Yes, the UK embassies act on behalf of nationals of the British
Commonwealth if they have no representation in country.  I'd not tag
that, either.  They already know it :-)

On 11/12/2018 2:36 PM, Warin wrote:
> On 12/11/18 18:31, Colin Smale wrote:
>>
>> On 2018-11-11 21:51, Graeme Fitzpatrick wrote:
>>
>>> Just for the sake of asking a theoretical question that I know would
>>> probably never appear in real life :-)
>>>  
>>> Would / could you also use the multi-letter codes as you show eg
>>> NATO, WTO, SEATO?
>>>  
>>> & a mixture of them, so the British Ambassador to Belgium, who is
>>> also the delegate / representative to NATO (if there is such a
>>> thing?), would be
>>> country=GB
>>> target=BE;NATO
>>>  
>> It's possible I guess to have the inverse of that as well, where the
>> embassy of e.g. France also houses the ambassador of e.g. Monaco,
>> both being accredited to the same receiving nation? (contrived example)
>>  
>> If a mission "represents" multiple countries, and the services
>> offered are different, how could that be tagged? Something like the
>> full Embassy of A also housing consular services for B.
>>  
>> Possibly two OSM objects, one for the embassy of A and a separate
>> node for the services on behalf of B?
>>  
> I do know that in the past one diplomatic establishment will act for
> another where the other has no representatives in that country. E.g
> Commonwealth countries would usually try to help one another out. And
> I think Russia also substitutes for some other adjacent countries. The
> services offered varied depending of the countries and place. I'd not
> tag it.
>
> ___
> 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] Add some tag to identify disputed borders

[Simon Poole]

I'm not a big fan of doing this.

There are only a very small number of countries, maybe none, that don't
have any sections of their borders that are disputed. While it can be
argued that moving away from our de facto area of control model allows
to reflect reality better, it also makes the borders essentially
unusable without making ~200 x "average number of border disputes"
decisions to get to a consistent set of border polygons (which is what
people want in the end).

Simon 

Am 12.11.2018 um 14:32 schrieb marc marc:
> it seems to me that there are 2 possible solutions
> - put the disputed area in the type=boundary boundary+administrative 
> relationship of the 2 countries and put dispute=yes on the way(s) concerned.
> - put the disputed area in neither of the two relationships.
> this area 'll be a mp, and thus a relation type=boundary 
> boundary=disputed make sense.
>
> it should also be ensured that it is a conflict and not simply
> an unintentional inconsistency caused by unshared way
> where they should have been
>
> Le 12. 11. 18 à 14:21, Noémie Lehuby a écrit :
>> Hi,
>>
>> Any thoughts about this ?
>>
>> Should we consider the dispusted=yes tag on boundary ways as a /de 
>> facto/ standard and uniformize a few borders ? Should we create a 
>> proposal about this tag ?
>> The borders data do not fit the doc and the statement from the 
>> Foundation and are not really usable right now...
>>
>> Noémie Lehuby
>> Qwant Research
>>
>> Le 26/10/2018 à 20:52, tagging-requ...@openstreetmap.org a écrit :
>>> Date: Fri, 26 Oct 2018 13:16:20 -0400
>>> From: Yuri Astrakhan
>>> To: "Tag discussion, strategy and related tools"
>>> 
>>> Subject: Re: [Tagging] Add some tag to identify disputed borders ?
>>> Message-ID:
>>> 
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> 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 mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Not contrived at all in these days of tight budgets. I see no reason the 
inverse would not work. I’ll add it.

Sent from my iPhone

> On Nov 12, 2018, at 12:31 PM, Colin Smale  wrote:
> 
>> On 2018-11-11 21:51, Graeme Fitzpatrick wrote:
>> 
>> Just for the sake of asking a theoretical question that I know would 
>> probably never appear in real life :-)
>>  
>> Would / could you also use the multi-letter codes as you show eg NATO, WTO, 
>> SEATO?
>>  
>> & a mixture of them, so the British Ambassador to Belgium, who is also the 
>> delegate / representative to NATO (if there is such a thing?), would be
>> country=GB
>> target=BE;NATO
>>  
> It's possible I guess to have the inverse of that as well, where the embassy 
> of e.g. France also houses the ambassador of e.g. Monaco, both being 
> accredited to the same receiving nation? (contrived example)
>  
> If a mission "represents" multiple countries, and the services offered are 
> different, how could that be tagged? Something like the full Embassy of A 
> also housing consular services for B.
>  
> Possibly two OSM objects, one for the embassy of A and a separate node for 
> the services on behalf of B?
>  
> ___
> 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] Add some tag to identify disputed borders

[marc marc]

it seems to me that there are 2 possible solutions
- put the disputed area in the type=boundary boundary+administrative 
relationship of the 2 countries and put dispute=yes on the way(s) concerned.
- put the disputed area in neither of the two relationships.
this area 'll be a mp, and thus a relation type=boundary 
boundary=disputed make sense.

it should also be ensured that it is a conflict and not simply
an unintentional inconsistency caused by unshared way
where they should have been

Le 12. 11. 18 à 14:21, Noémie Lehuby a écrit :
> Hi,
> 
> Any thoughts about this ?
> 
> Should we consider the dispusted=yes tag on boundary ways as a /de 
> facto/ standard and uniformize a few borders ? Should we create a 
> proposal about this tag ?
> The borders data do not fit the doc and the statement from the 
> Foundation and are not really usable right now...
> 
> Noémie Lehuby
> Qwant Research
> 
> Le 26/10/2018 à 20:52, tagging-requ...@openstreetmap.org a écrit :
>> Date: Fri, 26 Oct 2018 13:16:20 -0400
>> From: Yuri Astrakhan
>> To: "Tag discussion, strategy and related tools"
>>  
>> Subject: Re: [Tagging] Add some tag to identify disputed borders ?
>> Message-ID:
>>  
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Noémie Lehuby]

Hi,

Any thoughts about this ?

Should we consider the dispusted=yes tag on boundary ways as a /de 
facto/ standard and uniformize a few borders ? Should we create a 
proposal about this tag ?
The borders data do not fit the doc and the statement from the 
Foundation and are not really usable right now...


Noémie Lehuby
Qwant Research

Le 26/10/2018 à 20:52, tagging-requ...@openstreetmap.org a écrit :

Date: Fri, 26 Oct 2018 13:16:20 -0400
From: Yuri Astrakhan 
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] Add some tag to identify disputed borders ?
Message-ID:

Content-Type: text/plain; charset="utf-8"

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

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

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

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


Hello,

There seems to be no actual consensus on the way to map disputed borders.
The statement from the Foundation

recommend to map the border that "best meets realities on the ground" but
it's not what is actually in our database:
See for instance :
https://www.openstreetmap.org/#map=12/45.8481/18.8378
https://framapic.org/kIvnPSllBtnv/h1J8xti7US1F.gif
Both borders (according to Croatia vs according to Serbia) are mapped.

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

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

--
Noémie Lehuby
Qwant Research

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

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

Re: [Tagging] tagging for an office of the local representative to parliament

[Martin Koppenhoefer]

sent from a phone

> On 7. Nov 2018, at 02:28, Graeme Fitzpatrick  wrote:
> 
> Maybe change the title a little bit: "office of an elected official"?


maybe this goes too far?

Cheers, Martin 

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

Re: [Tagging] Estimated values for height

[Sergio Manzi]

... because, as you correctly point out, comments are just a human-to-human 
thing (/let's put AI aside for the moment.../), while a structured information 
for accuracy could open the way to an automated method to "/update this 
information only if the accuracy of this new measure is better than the old 
one/".

On 2018-11-12 11:30, Warin wrote:
> I think the only people who are going to see those indications of accuracy 
> are other mappers.
> In which case .. why not use a note, a comment ...human to human.
> There is no need to complicate it with rigid computer organised tags.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Warin]

On 12/11/18 21:23, Sergio Manzi wrote:


Please, just forget about trees (/and the fact that they obviously 
grow.../): trees have only been the "/casus belli/", the case for 
which we asked ourselves how "Estimated values for height" (/the topic 
of this thread.../) should be tagged.


The real question, I think, is if it is correct to have all those 
est_* keys or there could be a better way to indicate the accuracy of 
a measure.




I think the only people who are going to see those indications of 
accuracy are other mappers.

In which case .. why not use a note, a comment ...human to human.
There is no need to complicate it with rigid computer organised tags.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Warin]

On 12/11/18 21:01, Martin Koppenhoefer wrote:

Just add the height.



+1.

Some mappers are reluctant to change previous entries because they think 
the previous mapper might object or have better data.
I sometimes include a comment about how rough my entry is, thinking that 
someone can improve it.




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

Re: [Tagging] Estimated values for height

[Sergio Manzi]

Please, just forget about trees (/and the fact that they obviously grow.../): 
trees have only been the "/casus belli/", the case for which we asked ourselves 
how "Estimated values for height" (/the topic of this thread.../) should be 
tagged.

The real question, I think, is if it is correct to have all those est_* keys or 
there could be a better way to indicate the accuracy of a measure.

Cheers,

Sergio


On 2018-11-12 11:01, Martin Koppenhoefer wrote:
>
> I believe there is way too much fuzz about this, almost every number in OSM 
> is estimated, the height of a tree cannot be measured to the mm even with the 
> most precise instruments (and even if you could, it would be outdated within 
> the same day). Just add the height.
>
> Cheers,
> Martin


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Martin Koppenhoefer]

Am So., 11. Nov. 2018 um 17:11 Uhr schrieb Andy Townsend :

> No, putting a source on an object is not "bad practice".  If the source
> for all of the objects in a changeset is the same then of course it
> makes sense to use a changeset tag for the source rather than repeating
> the same object tag many times, but if different objects in the
> changeset have different sources then it is extremely helpful to other
> mappers to include them.  It's not compulsory (almost nothing is in OSM)
> but it can be helpful.




it is also good practice to divide/structure your changesets according to
the sources, so that it doesn't happen you have different sources within
the same changeset, at least not deliberately (by adding source tags to the
objects).

I see lots of (for example) "source=bing" which likely imply traced by a
mapper as seen on aerial imagery from Bing (but it could also mean she
imported the object from data released by Bing, or based on a website found
through bing, etc.), and his tag is completely worthless if I don't look at
the history to see which things have been modified or added or deleted in
the changeset that introduced the tag, and I must also verify that all
edits that came later didn't change these things (and the mapper simply
kept the source tag without updating it).

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

Re: [Tagging] Estimated values for height

[Martin Koppenhoefer]

Am So., 11. Nov. 2018 um 12:17 Uhr schrieb Sergio Manzi :

> Hello everybody,
>
> I'm the one who, in the Italian mailing list, first brought out the issue
> about how to tag estimated heights (*in our context it was about trees
> height*).
>
> My first proposal has been to use a new sub-key in which to store
> estimated values, as in "height:estimated=10".
>
> Then I saw, here, the proposal of using "source:height=estimated", which
> is in use (*1543 entries, mostly applied to ways: see: *[1]), which I
> thought was a better solution then the one I originally conceived.
>
> Now I see that there is a different solution in use,
> "height:source=estimated", which is less used (*149 entries, mostly
> applied to ways: see: *[2]), but *makes even more sense to me, from a
> syntactical point of view*.
>
> Someone also proposed to use "height:accuracy=*" if the accuracy is known,
> but I think this could be used for an estimated value too
> (height:accuracy=estimated). On the other hand this doesn't seems to be in
> use anywhere even though it might be considered an even better solution
> both syntactically and semantically (*I think "source" should be used to
> identify "who" is the originator of the information*).
>
> In any case I think the various est_(width|length|height|whatever) keys
> should be deprecated and a new universal solution to identify estimated
> values  should be adopted, taken from the ones described above (*or a new
> one I'm not thinking of** at this time*)*.*
>



I believe there is way too much fuzz about this, almost every number in OSM
is estimated, the height of a tree cannot be measured to the mm even with
the most precise instruments (and even if you could, it would be outdated
within the same day). Just add the height.

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

Re: [Tagging] How to tag named group of named water areas?

[Martin Koppenhoefer]

Am So., 11. Nov. 2018 um 22:54 Uhr schrieb Paul Allen :

> I have to say I far prefer the editors in things like WordPress and
> Drupal.  View source means HTML
> source and the visual editors seem (to me) better designed.
>



I agree that in an attempt to simplify html editing by introducing a markup
language, it became more complicated, not less, at least if you are
familiar with html, because it means you have to learn another syntax (wiki
markup), and yet another one (markdown), and yet another one, etc.

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

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Warin]

On 12/11/18 18:31, Colin Smale wrote:


On 2018-11-11 21:51, Graeme Fitzpatrick wrote:

Just for the sake of asking a theoretical question that I know would 
probably never appear in real life :-)
Would / could you also use the multi-letter codes as you show eg 
NATO, WTO, SEATO?
& a mixture of them, so the British Ambassador to Belgium, who is 
also the delegate / representative to NATO (if there is such a 
thing?), would be

country=GB
target=BE;NATO
It's possible I guess to have the inverse of that as well, where the 
embassy of e.g. France also houses the ambassador of e.g. Monaco, both 
being accredited to the same receiving nation? (contrived example)
If a mission "represents" multiple countries, and the services offered 
are different, how could that be tagged? Something like the full 
Embassy of A also housing consular services for B.
Possibly two OSM objects, one for the embassy of A and a separate node 
for the services on behalf of B?
I do know that in the past one diplomatic establishment will act for 
another where the other has no representatives in that country. E.g 
Commonwealth countries would usually try to help one another out. And I 
think Russia also substitutes for some other adjacent countries. The 
services offered varied depending of the countries and place. I'd not 
tag it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging