Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

2018-11-27 Thread Marc Gemis
I'm trying to understand how the current situation in Crimea has to be
mapped with your proposal.
The Ukranian community wants the old border (before the Russian
invasion) to be the de-facto border.
I assume that the Russian community wants the border elsewhere, so
Crimea becomes Russian territory. Since Crimea is occupied/controlled
by the Russians, one could expect that some mappers will place the
de-facto border so that Crimea falls in Russia.

Can you elaborate how we would map the situation to the satisfaction
of both groups ?

m

On Tue, Nov 27, 2018 at 8:30 AM Johnparis  wrote:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries
>
> On Tue, Nov 27, 2018 at 4:31 AM Daniel Koć  wrote:
>>
>> W dniu 27.11.2018 o 03:21, Johnparis pisze:
>> > A general proposal to address mapping disputed borders at the national
>> > level.
>>
>>
>> What is the link to this RFC? This one seems to be old and abandoned:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/DisputedTerritories
>>
>>
>> --
>> "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

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


Re: [Tagging] [OSM-talk] Feature Proposal - RFC - Mapping disputed boundaries

2018-11-27 Thread Roland Olbricht

Hi all,

a much simpler approach is to look into the respective constitution.

The Ukrainian constitution defines the state's territory in article 133. 
Other countries, like Germany do so as well, and Ireland does or has 
done so. France does not define its terriotry in the constitution, and 
the UK has AFAIK no constituation. Probably in both countires laws exist.


Thus I suggest to create a relation comprising the regions mentioned in 
that said article. It should hold the various name tags and a distinct 
tag (not "boundary", "admin_level", or "source") to indicate that it is 
a boundary according to the consitution, e.g. 
"legitimation=constitution" (and "legitimation=national_law" if not 
declared by the constitution). Countries where the constitution 
conincides with the de-facto border can just get the tag.


For Cyprus and Western Sahara, I have been unable to find the relevant 
documents. I'm cautiously optimistic that they can be modeled in the 
same way.


Given that there is at most one constiution per country, that those are 
designed to change infrequently and most countries are expected to 
conincide, this allows to add no-nonsense data without opening a can of 
worms.


Best regards,

Roland

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


Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

2018-11-27 Thread Johnparis
>From the proposal: *The de facto border is the one that conforms to the
Policy's statement: "Currently, we record one set that, in OpenStreetMap
contributor opinion, is most widely internationally recognised and best
meets realities on the ground, generally meaning physical control."*

The question of "physical control" is, I believe, not at issue. The fact
that Russia exercises physical control is precisely what Ukraine objects
to. So both sides agree that Russia has physical control of Ukraine. But if
there were a dispute, again from the proposal: *Disputes about which
claiming entity, if any, exercises control over a particular territory can
be resolved by the OSM Institutions* (meaning the OSMF or the DWG). The
criterion of "most widely internationally recognised", and how it might
conflict with the criterion of "best meets realities on the ground", is at
issue. So the de facto situation remains one that the OSM Institutions
would have to resolve. When resolved, the de facto border would get the
"boundary:status=osm_designated" tag, which essentially makes it "not
subject to change" (by ordinary mappers, anyway).

The claims, which are new in the proposal, are relatively easier to
determine. A Ukraine supporter would map using the Ukrainian claim; a
Russia supporter using the Russian claim. Both countries are members of the
UN, so both have the right to stake a claim.

"Mapping to the satisfaction of both groups" is probably impossible and
certainly not the goal of the proposal. Again, from the proposal:

*The purpose of this proposal is to advance the implementation of the
Policy on Disputed Territories

of the OSM Foundation ,
as implemented and enforced by its Data Working Group
 (referred
to collectively in this proposal as the OSM Institutions), and in
particular the policy's Summary Point 4, which states in part:*

*We recognise the importance of names, borders and descriptions to
different national, ethnic, culture or language groups. We have and will
continue to build mechanisms where alternatives can be recorded and easily
used in maps.*

The proposal offers a possible mechanism.

John








On Tue, Nov 27, 2018 at 9:12 AM Marc Gemis  wrote:

> I'm trying to understand how the current situation in Crimea has to be
> mapped with your proposal.
> The Ukranian community wants the old border (before the Russian
> invasion) to be the de-facto border.
> I assume that the Russian community wants the border elsewhere, so
> Crimea becomes Russian territory. Since Crimea is occupied/controlled
> by the Russians, one could expect that some mappers will place the
> de-facto border so that Crimea falls in Russia.
>
> Can you elaborate how we would map the situation to the satisfaction
> of both groups ?
>
> m
>
> On Tue, Nov 27, 2018 at 8:30 AM Johnparis  wrote:
> >
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries
> >
> > On Tue, Nov 27, 2018 at 4:31 AM Daniel Koć  wrote:
> >>
> >> W dniu 27.11.2018 o 03:21, Johnparis pisze:
> >> > A general proposal to address mapping disputed borders at the national
> >> > level.
> >>
> >>
> >> What is the link to this RFC? This one seems to be old and abandoned:
> >>
> >>
> https://wiki.openstreetmap.org/wiki/Proposed_features/DisputedTerritories
> >>
> >>
> >> --
> >> "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
>
> ___
> 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 - Mapping disputed boundaries

2018-11-27 Thread Marc Gemis
On Tue, Nov 27, 2018 at 10:06 AM Johnparis  wrote:\

> The question of "physical control" is, I believe, not at issue. The fact that 
> Russia exercises physical control is precisely what Ukraine objects to. So 
> both sides agree that Russia has physical control of Ukraine. But if there 
> were a dispute, again from the proposal: Disputes about which claiming 
> entity, if any, exercises control over a particular territory can be resolved 
> by the OSM Institutions (meaning the OSMF or the DWG). The criterion of "most 
> widely internationally recognised", and how it might conflict with the 
> criterion of "best meets realities on the ground", is at issue. So the de 
> facto situation remains one that the OSM Institutions would have to resolve. 
> When resolved, the de facto border would get the 
> "boundary:status=osm_designated" tag, which essentially makes it "not subject 
> to change" (by ordinary mappers, anyway).

From https://www.openstreetmap.org/user/Kilkenni/diary/47017#comment43421
I understand that the notion using  "physical control" to define the
border is the problem.

m.

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


Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

2018-11-27 Thread Johnparis
Thank you for that reference, Marc.

The blog post you cite deals with the policy and how it is enforced, not
with the question of physical control. The blog acknowledges that Russia
has physical control.

Let me be clear: this proposal makes NO CHANGES in the existing policy
regarding de facto borders, and makes NO CHANGES in how that policy is
implemented (other than to explicitly tag borders where OSMF has made a
ruling).

Discussions of the existing policy and its enforcement are therefore not on
topic. I personally have issues with the policy (it has led to, shall we
say, rather "unique" maps in many parts of the world), but those are
properly directed at the OSMF and the DWG. They are not relevant to this
proposal.

This proposal offers a mechanism, if you will, for the "losing side" in a
ruling by the OSMF to "have its say" on the map. It does not absolve OSMF
from its role in making a ruling.

The proposal works regardless of how OSMF decides to enforce (or change)
its policy. Hypothetically, OSMF could decide that henceforth, all de facto
borders will be taken from the 1923 Atlas of the World by Encyclopaedia
Britannica. (That would lift one burden from them!) This proposal would
remain the same.

John




On Tue, Nov 27, 2018 at 10:20 AM Marc Gemis  wrote:

> On Tue, Nov 27, 2018 at 10:06 AM Johnparis  wrote:\
>
> > The question of "physical control" is, I believe, not at issue. The fact
> that Russia exercises physical control is precisely what Ukraine objects
> to. So both sides agree that Russia has physical control of Ukraine. But if
> there were a dispute, again from the proposal: Disputes about which
> claiming entity, if any, exercises control over a particular territory can
> be resolved by the OSM Institutions (meaning the OSMF or the DWG). The
> criterion of "most widely internationally recognised", and how it might
> conflict with the criterion of "best meets realities on the ground", is at
> issue. So the de facto situation remains one that the OSM Institutions
> would have to resolve. When resolved, the de facto border would get the
> "boundary:status=osm_designated" tag, which essentially makes it "not
> subject to change" (by ordinary mappers, anyway).
>
> From https://www.openstreetmap.org/user/Kilkenni/diary/47017#comment43421
> I understand that the notion using  "physical control" to define the
> border is the problem.
>
> m.
>
> ___
> 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 - Voting - boundary=aboriginal_lands

2018-11-27 Thread Martin Koppenhoefer


sent from a phone

> On 27. Nov 2018, at 03:27, Paul Johnson  wrote:
> 
> I'm generally a fan of the admin_level option.  protected_area is OKisn, but 
> the protect_class=* tag definitely hits me as an oddity given other tagging.  
> boundary=aboriginal_lands could be a supplemental tag to admin_level.


+1, 
admin_level is fine where it applies (maybe everywhere, not sure, it requires 
the land to be an administrative entity which might not always be the case). 
But it doesn’t tell you it is about land that the invaders gave to the native 
population, so an additional tag is desirable.

I agree that protected_class is not sustainable (numbers as values are harder 
to remember and easier to confuse).

The proposed boundary=aboriginal_lands seems quite ok. Would this be combinable 
with admin_level, or would you insist on boundary=administrative? The fact that 
both „main keys“ might apply sometimes seems to be a problem: either you tag 
these as b=administrative and still haven’t said it is about native population 
areas, or you use b=aboriginal_lands and as a result you get administrative 
entities that are not tagged as b=administrative 


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


Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

2018-11-27 Thread Paul Johnson
On Tue, Nov 27, 2018, 07:10 Martin Koppenhoefer 
>
> sent from a phone
>
> > On 27. Nov 2018, at 03:27, Paul Johnson  wrote:
> >
> > I'm generally a fan of the admin_level option.  protected_area is OKisn,
> but the protect_class=* tag definitely hits me as an oddity given other
> tagging.  boundary=aboriginal_lands could be a supplemental tag to
> admin_level.
>
>
> +1,
> admin_level is fine where it applies (maybe everywhere, not sure, it
> requires the land to be an administrative entity which might not always be
> the case). But it doesn’t tell you it is about land that the invaders gave
> to the native population, so an additional tag is desirable.
>
> I agree that protected_class is not sustainable (numbers as values are
> harder to remember and easier to confuse).
>
> The proposed boundary=aboriginal_lands seems quite ok. Would this be
> combinable with admin_level, or would you insist on
> boundary=administrative? The fact that both „main keys“ might apply
> sometimes seems to be a problem: either you tag these as b=administrative
> and still haven’t said it is about native population areas, or you use
> b=aboriginal_lands and as a result you get administrative entities that are
> not tagged as b=administrative
>

At least in the US and Canada, indian territories, reservations, reserves
and administrative areas are du jure administrative boundaries.

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


Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

2018-11-27 Thread Kevin Kenny

On 11/26/18 6:35 PM, Clifford Snow wrote:
I can't speak for other countries so I'll limit my comments to the US. 
As Kevin Kenny commented, tribes in the US are recognized as domestic 
dependent nations.  But from there it gets messy. They can set their 
own sales tax separate from the state and have their own courts. Yet 
in North Dakota, the state determines voting requirements. For this 
reason I don't think admin_level works very well.


1. admin_level doesn't work in the US, period.

2. There's no good answer, but admin_level=3 might be a good compromise.

3. Occasionally the First Nations function as countries.

4. Just what the First Nations are is a political question with about 
four hundred years of bloody history. Occasional bloodshed continues to 
this day. We're not going to come up with a satisfactory answer here.


1.

There is no administrative unit in the US - except or the states and 
perhaps the counties (which not all states have) for which admin_level 
really works well. Counties in New York can set their own sales tax, and 
so can chartered Cities, two of which cross county lines. Landowners in 
a Village owe property tax to both the Village and the Town - and maybe 
a sixth of the Villages are in more than one Town. It's *all* messy.


And that's without accounting for special administrative districts for 
schools, libraries, police, garbage, sewers, fire brigades, water 
supply, ... New York has dozens of different flavors, none of which is 
constrained to the boundaries of anything else, and all of them have 
elected [or state-appointed] officials and the power to tax. We've never 
tried to settle how to tag these in OSM - we simply don't map the 
limited-purpose admin areas such as school districts.


The Europeans think the US system is totally insane, but it mostly 
works. In any case, it has to be a case of "we map what we have." Too 
often, what we hear from some individuals on this list is not very far 
removed from, "the tagging model is fine; fix your country!" That, of 
course, is not really an option that's available to us in the near future.


2.

As far as 'aboriginal lands' go, I'd be happy with either 
boundary=administrative or else a new sui generis boundary type. If it 
is to be 'administrative', I'd argue for the otherwise unused 
'admin-level' of 3, a compromise among a set of political alternatives 
that range from '2' (a country whose rights happen to be denied) to 
nothing at all (an illegitimate country issuing 'fantasy passports' with 
no more legal existence than self-proclaimed 'micro-nations'). Like all 
compromises, it will satisfy nobody, but at least acknowledge that a 
diversity of opinion exists.


3.

The larger among the First Nations surely have a messy status.

Some issue passports. The Cayuga statesman Levi General Deskaheh 
traveled to Great Britain in 1917 and Geneva in 1923 on a Haudenosaunee 
passport to plead for recognition of his people by the British crown and 
at the League of Nations. As recently as 2018, athletes from the 
Haudenosaunee Confederacy traveled on Haundenosaunee passports to 
compete in world-level events. Israel accepted the Haudenosaunee 
passport for their admission, and Canada, while not recognizing tribal 
sovereignty, offered assurances that the competitors would be 
repatriated. The US players crossed the US-Canada border at Akwesasne, 
where a US-UK treaty that allows FIrst Nations natives to pass has been 
in force - although often violated - since 1792. The US, Canada, and the 
Schengen nations, however, emphatically do *not* recognize the 
Haudenosaunee authority to issue passports.


4.

Referring to the Haudenosaunee as a 'tribe' is ... strange. The Six 
Nations are a federal republic with a constitution which they adopted in 
1142.  unwritten but widely memorized, since it has religious 
significance. Despite the oral nature of the history, it can be dated 
accurately because of an account of a solar eclipse. There is ample 
evidence that it was functioning as a republic in 1603, when Champlain 
first encountered them, and they were still functioning as such in 1722, 
when the Tuscarora Nation was admitted as a sixth member nation of the 
Haudenosaunee Confederacy. The Confederacy was, in some ways, the model 
for the US system of separate Federal and State sovereignty - and the 
Framers of the Constitution were well aware of it.


North Dakota, as you mention, is an odd case. It does not 'determine' 
the voting requirements for citizens of the dependent nations. It (along 
with fifteen other states) has power delegated to it by Congress to 
enforce Federal and tribal law on the reservations, and as such, is 
responsible for upholding the rights that the tribes have determined. 
It's an executive, not a legislative authority. In th The local sheriff, 
the tribal police, the Bureau of Indian Affairs, and the FBI all have 
jurisdiction to enforce Federal and tribal law. The resulting 
jurisdictional conflict 

[Tagging] My proposal for disputed country borders

2018-11-27 Thread Rory McCann

This is my suggestion for how to map disputed/claimed borders.
https://wiki.openstreetmap.org/wiki/Proposed_features/ClaimedBorders 
(but I appear to have broken the wiki).


This proposal is simple. Map the claimed border of a country according 
to another country as another regular {{Tag|type|boundary}} relation, 
but add {{Tag|boundary|claimed_administrative}} + 
{{Tag|claimed:admin_level||2}} (since we're nearly always dealing with 
countries) Add the regular tags for a boundary relation (e.g. 
{{Tag|ISO3166-1}}, {{Tag|name}}).


Then add {{Tag|according_to:XX||yes/no}} for each country that does or 
doesn't claims this is the border of the subject country. If 
{{Tag|according_to:XX}} is missing for an object, the value should be 
assumed to be "yes" if this is {{Tag|boundary|administrative}}, and "no" 
if it's {{Tag|boundary|claimed_administrative}}.


== Examples ==

=== Kosovo ===

{{Wikipedia|en|Kosovo|text=no}} has been 
{{Wikipedia|en|https://en.wikipedia.org/wiki/International_recognition_of_Kosovo 
 }} recognised by about half the members of the UN, since it is de 
facto  acting as a country, it's mapped in OSM {{relation|2088990}}, as 
{{Tag|boundary|administative}}+{{Tag|admin_level||2}}. Kosovo was part 
of Serbia, which is {{relation|1741311}}, and also 
{{Tag|boundary|administative}}+{{Tag|admin_level||2}}. Serbia & Spain 
don't recognise Kosovo, so I presume they view the border of "Serbia" to 
be the land covered by {{relation|2088990}}+{{relation|1741311}}. We can 
map this by copying the Serbia relation ({{relation|1741311}}), and 
changing the members to include the larger area, then add 
{{Tag|type|boundary}}+{{Tag|boundary|claimed_administrative}}+{{Tag|claimed:admin_level||2}}+{{Tag|ISO3166-1||RS}}+{{Tag|according_to:RS||yes}}+{{Tag|according_to:ES||yes}}.


We can add {{Tag|according_to:XK||yes}} to the Kosovo relation, since 
(IIRC) the de facto border is what the government there claims as the 
border. We can add {{Tag|according_to:RS||no}} to the Serbia relation, 
which means "This is the de facto border of Serbia, and they claim it's 
not the border, and the UK claims it is, and Mexico claims it isn't".


=== Crimea ===

Left as an exercise for the reader.

=== Kashmir ===

(Correct me if I'm wrong) {{Wikipedia|en|Kashmir conflict}} is mostly a 
dispute between India and Pakistan, but China has claims on some parts. 
Neither India or Pakistan control all of what they claim. (i) The de 
facto border of India, (ii) The de facto border of Pakistan (current OSM 
countries), (iii) The borders of India according to India, (iv) The 
borders of Pakistan accroding to India, (v) The borders of Pakistan 
according to Pakistan, (vi) The borders of India according to Pakistan.


Each of these 6 options would be mapped with a separate relation.

== Advantages ==

* Copies the same logic from multipolygons, being supported by
* 100% backwards compatible with existing scheme to map countries
* Easily readable tags that data consumers can probably deduce.

== Disadvantages ==

* Creates more relations, several extra per disputed area. This could be 
unwieldy an could lead to data consistancies


== Using the data ==

=== Rendering a Map ===

To render a map of the world with the Serbian view of borders, you 
import the data with `osm2pgsql`, then run a SQL query like:


DELETE FROM planet_osm_polygon WHERE boundary = 'administrative' AND 
'admin_level'='2' AND tags->'claimed:by:RS' = 'no',
UPDATE planet_osm_polygon SET admin_level = '2', boundary = 
'administrative' WHERE boundary = 'claimed_administrative' AND 
'claimed_admin_level'='2' AND tags->'claimed:by:RS' = 'yes',


or an SQL VIEW could be used.

(Or adjust your map style appropriately to look at the 
{{Tag|according_to:XX}} tag, with a reasonable default).


=== Data analysis ===

With an osm2pgsql database, you can see what areas are claimed by 
country X, but not de facto controlled by it.


== See also ==

* [[Proposed features/Mapping disputed boundaries]]
* [[Proposed_features/DisputedTerritories|Previous (abandoned) 
proposal]] on mapping disputed territories.



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


Re: [Tagging] My proposal for disputed country borders

2018-11-27 Thread Joseph Eisenberg
This proposal has several problems:
1) Too many new relations, up to 180 per border or whatever the number of
independent states has reached.

2) OSM is for “real, current” data
- Claimed borders are not real.
- Many old claims have never been officially surrendered

3) “Don’t map your local legislation”
- legislation in country X has no jurisdiction in country Y

These last two points are in the good mapping practice wiki page and 2) is
on the main page for new mappers
On Wed, Nov 28, 2018 at 6:43 AM Rory McCann  wrote:

> This is my suggestion for how to map disputed/claimed borders.
> https://wiki.openstreetmap.org/wiki/Proposed_features/ClaimedBorders
> (but I appear to have broken the wiki).
>
> This proposal is simple. Map the claimed border of a country according
> to another country as another regular {{Tag|type|boundary}} relation,
> but add {{Tag|boundary|claimed_administrative}} +
> {{Tag|claimed:admin_level||2}} (since we're nearly always dealing with
> countries) Add the regular tags for a boundary relation (e.g.
> {{Tag|ISO3166-1}}, {{Tag|name}}).
>
> Then add {{Tag|according_to:XX||yes/no}} for each country that does or
> doesn't claims this is the border of the subject country. If
> {{Tag|according_to:XX}} is missing for an object, the value should be
> assumed to be "yes" if this is {{Tag|boundary|administrative}}, and "no"
> if it's {{Tag|boundary|claimed_administrative}}.
>
> == Examples ==
>
> === Kosovo ===
>
> {{Wikipedia|en|Kosovo|text=no}} has been
> {{Wikipedia|en|
> https://en.wikipedia.org/wiki/International_recognition_of_Kosovo
>   }} recognised by about half the members of the UN, since it is de
> facto  acting as a country, it's mapped in OSM {{relation|2088990}}, as
> {{Tag|boundary|administative}}+{{Tag|admin_level||2}}. Kosovo was part
> of Serbia, which is {{relation|1741311}}, and also
> {{Tag|boundary|administative}}+{{Tag|admin_level||2}}. Serbia & Spain
> don't recognise Kosovo, so I presume they view the border of "Serbia" to
> be the land covered by {{relation|2088990}}+{{relation|1741311}}. We can
> map this by copying the Serbia relation ({{relation|1741311}}), and
> changing the members to include the larger area, then add
>
> {{Tag|type|boundary}}+{{Tag|boundary|claimed_administrative}}+{{Tag|claimed:admin_level||2}}+{{Tag|ISO3166-1||RS}}+{{Tag|according_to:RS||yes}}+{{Tag|according_to:ES||yes}}.
>
> We can add {{Tag|according_to:XK||yes}} to the Kosovo relation, since
> (IIRC) the de facto border is what the government there claims as the
> border. We can add {{Tag|according_to:RS||no}} to the Serbia relation,
> which means "This is the de facto border of Serbia, and they claim it's
> not the border, and the UK claims it is, and Mexico claims it isn't".
>
> === Crimea ===
>
> Left as an exercise for the reader.
>
> === Kashmir ===
>
> (Correct me if I'm wrong) {{Wikipedia|en|Kashmir conflict}} is mostly a
> dispute between India and Pakistan, but China has claims on some parts.
> Neither India or Pakistan control all of what they claim. (i) The de
> facto border of India, (ii) The de facto border of Pakistan (current OSM
> countries), (iii) The borders of India according to India, (iv) The
> borders of Pakistan accroding to India, (v) The borders of Pakistan
> according to Pakistan, (vi) The borders of India according to Pakistan.
>
> Each of these 6 options would be mapped with a separate relation.
>
> == Advantages ==
>
> * Copies the same logic from multipolygons, being supported by
> * 100% backwards compatible with existing scheme to map countries
> * Easily readable tags that data consumers can probably deduce.
>
> == Disadvantages ==
>
> * Creates more relations, several extra per disputed area. This could be
> unwieldy an could lead to data consistancies
>
> == Using the data ==
>
> === Rendering a Map ===
>
> To render a map of the world with the Serbian view of borders, you
> import the data with `osm2pgsql`, then run a SQL query like:
>
> DELETE FROM planet_osm_polygon WHERE boundary = 'administrative' AND
> 'admin_level'='2' AND tags->'claimed:by:RS' = 'no',
> UPDATE planet_osm_polygon SET admin_level = '2', boundary =
> 'administrative' WHERE boundary = 'claimed_administrative' AND
> 'claimed_admin_level'='2' AND tags->'claimed:by:RS' = 'yes',
>
> or an SQL VIEW could be used.
>
> (Or adjust your map style appropriately to look at the
> {{Tag|according_to:XX}} tag, with a reasonable default).
>
> === Data analysis ===
>
> With an osm2pgsql database, you can see what areas are claimed by
> country X, but not de facto controlled by it.
>
> == See also ==
>
> * [[Proposed features/Mapping disputed boundaries]]
> * [[Proposed_features/DisputedTerritories|Previous (abandoned)
> proposal]] on mapping disputed territories.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@o

Re: [Tagging] My proposal for disputed country borders

2018-11-27 Thread Yuri Astrakhan
Rory, thanks for tackling this. You might want to re-upload your proposal
to the wiki, as it does appear to be borked at the moment.

I think we should not store undisputed territories in the same relation as
the disputed ones.  Lets just store the disputed regions as individual
relations, e.g. Kurill's islands, Kosovo, Crimea, etc., and each of them
will have two or more "claimed_by_XX" tags.  Crimea for example would have
"claimed_by_RU=AM;BE;..." (alphabetized), and "claimed_by_UE=*".  The *
means everyone else who is not listed in the other "claimed_by_...". This
way the list is small enough to be manageable, and we do not have hundreds
of yes/no flags.

This will make it very easy to consume, by simply subtracting disputed
territories from the official country's claims based on the target audience.

Example:   drawing a map of Europe for someone in France would draw Ukraine
without alterations (FR is part of the "claimed_by_UE=*" wildcard), and
Russia as "Russia minus Crimea" because FR is not listed in the
"claimed_by_RU" tag.


On Tue, Nov 27, 2018 at 4:43 PM Rory McCann  wrote:

> This is my suggestion for how to map disputed/claimed borders.
> https://wiki.openstreetmap.org/wiki/Proposed_features/ClaimedBorders
> (but I appear to have broken the wiki).
>
> This proposal is simple. Map the claimed border of a country according
> to another country as another regular {{Tag|type|boundary}} relation,
> but add {{Tag|boundary|claimed_administrative}} +
> {{Tag|claimed:admin_level||2}} (since we're nearly always dealing with
> countries) Add the regular tags for a boundary relation (e.g.
> {{Tag|ISO3166-1}}, {{Tag|name}}).
>
> Then add {{Tag|according_to:XX||yes/no}} for each country that does or
> doesn't claims this is the border of the subject country. If
> {{Tag|according_to:XX}} is missing for an object, the value should be
> assumed to be "yes" if this is {{Tag|boundary|administrative}}, and "no"
> if it's {{Tag|boundary|claimed_administrative}}.
>
> == Examples ==
>
> === Kosovo ===
>
> {{Wikipedia|en|Kosovo|text=no}} has been
> {{Wikipedia|en|
> https://en.wikipedia.org/wiki/International_recognition_of_Kosovo
>   }} recognised by about half the members of the UN, since it is de
> facto  acting as a country, it's mapped in OSM {{relation|2088990}}, as
> {{Tag|boundary|administative}}+{{Tag|admin_level||2}}. Kosovo was part
> of Serbia, which is {{relation|1741311}}, and also
> {{Tag|boundary|administative}}+{{Tag|admin_level||2}}. Serbia & Spain
> don't recognise Kosovo, so I presume they view the border of "Serbia" to
> be the land covered by {{relation|2088990}}+{{relation|1741311}}. We can
> map this by copying the Serbia relation ({{relation|1741311}}), and
> changing the members to include the larger area, then add
>
> {{Tag|type|boundary}}+{{Tag|boundary|claimed_administrative}}+{{Tag|claimed:admin_level||2}}+{{Tag|ISO3166-1||RS}}+{{Tag|according_to:RS||yes}}+{{Tag|according_to:ES||yes}}.
>
> We can add {{Tag|according_to:XK||yes}} to the Kosovo relation, since
> (IIRC) the de facto border is what the government there claims as the
> border. We can add {{Tag|according_to:RS||no}} to the Serbia relation,
> which means "This is the de facto border of Serbia, and they claim it's
> not the border, and the UK claims it is, and Mexico claims it isn't".
>
> === Crimea ===
>
> Left as an exercise for the reader.
>
> === Kashmir ===
>
> (Correct me if I'm wrong) {{Wikipedia|en|Kashmir conflict}} is mostly a
> dispute between India and Pakistan, but China has claims on some parts.
> Neither India or Pakistan control all of what they claim. (i) The de
> facto border of India, (ii) The de facto border of Pakistan (current OSM
> countries), (iii) The borders of India according to India, (iv) The
> borders of Pakistan accroding to India, (v) The borders of Pakistan
> according to Pakistan, (vi) The borders of India according to Pakistan.
>
> Each of these 6 options would be mapped with a separate relation.
>
> == Advantages ==
>
> * Copies the same logic from multipolygons, being supported by
> * 100% backwards compatible with existing scheme to map countries
> * Easily readable tags that data consumers can probably deduce.
>
> == Disadvantages ==
>
> * Creates more relations, several extra per disputed area. This could be
> unwieldy an could lead to data consistancies
>
> == Using the data ==
>
> === Rendering a Map ===
>
> To render a map of the world with the Serbian view of borders, you
> import the data with `osm2pgsql`, then run a SQL query like:
>
> DELETE FROM planet_osm_polygon WHERE boundary = 'administrative' AND
> 'admin_level'='2' AND tags->'claimed:by:RS' = 'no',
> UPDATE planet_osm_polygon SET admin_level = '2', boundary =
> 'administrative' WHERE boundary = 'claimed_administrative' AND
> 'claimed_admin_level'='2' AND tags->'claimed:by:RS' = 'yes',
>
> or an SQL VIEW could be used.
>
> (Or adjust your map style appropriately to look at the
> {{Tag|according_to:XX}} tag, with a reasonable 

Re: [Tagging] My proposal for disputed country borders

2018-11-27 Thread Andy Townsend

On 27/11/2018 23:01, Joseph Eisenberg wrote:

This proposal has several problems:
1) Too many new relations, up to 180 per border or whatever the number 
of independent states has reached.


It's a concern (I've made similar points about languages in the past) 
but in this case I don't think that there will be _that_ many new border 
relations.  To take Ukraine as an example, there will only I suspect be 
one extra relation, with a very large number of "according_to:XX" tags 
as almost everyone supports Ukraine's border claim, but it doesn't match 
the current line of control.  You might get up to a dozen in some areas 
(perhaps around the South China Sea, also UK with or without Chagos 
Archipelago, Falklands, Gibraltar etc.), but I suspect not many more 
than that.




2) OSM is for “real, current” data
- Claimed borders are not real.
- Many old claims have never been officially surrendered


It's true that verifiability is an issue here (the problems with some 
historic claims were mentioned in a previous thread) but in many cases 
there really isn't an argument about _where_ the border is, only _what_ 
the status of the thing within it has, and (taking Ukraine as an example 
again) I'd suggest that the statement "Ukraine claims that Crimea is 
part of Ukraine" is very verifiable.




3) “Don’t map your local legislation”
- legislation in country X has no jurisdiction in country Y
Where the wiki says "Don't map your local legislation" it's again just 
making a point about verifiability.  "legislation in country X has no 
jurisdiction in country Y" doesn't seem to exist in the OSM wiki at all; 
so I guess that you're just saying that _only_ de facto boundaries 
should be in OSM?  That's nearly where we are now, except that we do 
have a border for e.g. Western Sahara, and attempts have been made to 
map the claims between India, China and Pakistan (but not currently the 
resulting claimed country borders).


On Wed, Nov 28, 2018 at 6:43 AM Rory McCann > wrote:


This is my suggestion for how to map disputed/claimed borders.
https://wiki.openstreetmap.org/wiki/Proposed_features/ClaimedBorders
(but I appear to have broken the wiki).
(text snipped)
== Examples ==



Just a thought - how about uploading some examples as a test to the dev 
server (or elsewhere) to allow people to experiment with the data?  It's 
often easier to see potential problems once you're actually trying to 
process the data rather than in the abstract.


Best Regards,

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


Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

2018-11-27 Thread Doug Hembry

On 11/26/18 17:00, Mateusz Konieczny wrote:
 >> and I fail to see how much more
 >> difficult it is to tag "boundary=protected area" and 
"protect_class=24"
 >
 > Because "24" is a completely random code, unlike 
boundary=aboriginal_lands

And on 11/26/18 17:00, Frederick Ramm wrote:
 >We generally *try* and make our data human-readable. If archaeologists
 >dig up an old planet file in 1000 years, then finding a tag
 >boundary=aboriginal_lands is more useful to them than protect_class=24.
(Thanks for the levity, Frederick. And I take the point, but see below)

Mateusz and Frederick,
Everyone seems to have forgotten boundary=administrative with its 
associated admin_level=n tag, which IMHO is pretty analogous to 
boundary=protected_area with its protect_class=n tag. They even both 
have look-up tables by country. And the class numbers are not arbitrary, 
Mateusz, - they map to IUCN categories.

But seriously, how many aboriginal lands do you think a mapper would 
have to tag before they remember "protect_class=24"?

And, as for the future archaeologists, and "human readable": Correct use 
of the boundary=protected_area tag actually requires the use of 
protect_title=* tag that provides users with the human readable title of 
this area-type (note: not the "name", which may also be present). ie, 
protect_title= Indigenous Protected Areas, or Indian Reservations, or 
Terra Indigena, or Territorio Indigena, etc,.. (to borrow from the 
proposal page), or perhaps just "aboriginal_lands" as a default. The 
protect_class groups the area-types of broadly similar purpose and/or 
level of protection out of what could be hundreds of variously titled 
protected-area-types around the world. Future archaeologists should be 
pleased.

But although I don't buy your "numbers are bad" argument - nevertheless, 
having read the other comments on this topic I am almost persuaded that 
protected_area is not really appropriate to describe what is essentially 
a sovereign country. It might even be considered demeaning. Something 
based on administrative boundaries (which I don't have much experience 
of) might be better. I still think introducing another top-level 
"boundary= aboriginal_lands" tag is wrong. If we're not careful, 
boundary=  will wind up like amenity=* - too many darned fragmented 
values under one tag. But I'm dropping out of this particular discussion 
(... and there was much rejoicing :-))

What I'm really interested in is the use of boundary=protected_area to 
accurately describe Nature-protected-areas and 
Resources-protected-areas. The "numbers are bad" assertion worries me 
and prompts a broader question: if this is "policy", does it mean that 
boundary=protected_area, and protect_class=* tags are doomed in OSM? 
Have we found the covert reason why carto still doesn't render it, 
despite the fact that it could be rendered (at least initially) exactly 
like boundary=national_park? And despite the fact that there are 70,000 
uses  around the planet? Could we be excused for suspecting that there 
is an "OSM Establishment" who would like to see it deprecated and go 
away? OK, maybe I have a nasty suspicious mind - but I can't help 
wondering. If true, could someone please come clean and just tell us to 
stop using it (and tell us what else to use)?

I'm also wondering (an even broader question) at the justification for 
making a decision like this (the approval of boundary=aboriginal_lands) 
on the basis of 20 or so votes (so far, hopefully more to come)  mostly 
from involved and passionate supporters of the proposal out of the 
hundreds of thousands in the OSM community. Where are the OSM'ers who 
originally created the boundary=protected_area proposal and got it 
approved. Have they voted? And likewise for all the mappers responsible 
for the 70,000 uses? Have we had any involvement from South American 
mappers, where there seem to be a lot of protect_class=24 uses? This is 
clearly a question for another time (and mailing list) and it may have 
come up before, but it IMHO we need a more broadly based way of deciding 
things like this.

Cheers..



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


Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

2018-11-27 Thread Joseph Eisenberg
Re “Have we found the covert reason why carto still doesn't render
[Protected areas]”

No need for conspiracy theories. We simply need more contributors at
openstreetmap-carto who are willing to volunteer their time to fix these
issues.

But we are about to start rendering the equivalent protected_class
boundaries for national parks and nature reserves in the next release, this
month:

And we would like to render aboriginal_lands and protect_class=24 in the
same style, as a brownish outline, unless there are clear objections to one
of the tags.

See: https://github.com/gravitystorm/pull/3509 “Add rendering for
protected_area”
And
https://github.com/gravitystorm/pull/3521 “Add Aboriginal Areas”

-Joseph

On Wed, Nov 28, 2018 at 10:55 AM Doug Hembry  wrote:

>
> On 11/26/18 17:00, Mateusz Konieczny wrote:
>  >> and I fail to see how much more
>  >> difficult it is to tag "boundary=protected area" and
> "protect_class=24"
>  >
>  > Because "24" is a completely random code, unlike
> boundary=aboriginal_lands
>
> And on 11/26/18 17:00, Frederick Ramm wrote:
>  >We generally *try* and make our data human-readable. If archaeologists
>  >dig up an old planet file in 1000 years, then finding a tag
>  >boundary=aboriginal_lands is more useful to them than protect_class=24.
> (Thanks for the levity, Frederick. And I take the point, but see below)
>
> Mateusz and Frederick,
> Everyone seems to have forgotten boundary=administrative with its
> associated admin_level=n tag, which IMHO is pretty analogous to
> boundary=protected_area with its protect_class=n tag. They even both
> have look-up tables by country. And the class numbers are not arbitrary,
> Mateusz, - they map to IUCN categories.
>
> But seriously, how many aboriginal lands do you think a mapper would
> have to tag before they remember "protect_class=24"?
>
> And, as for the future archaeologists, and "human readable": Correct use
> of the boundary=protected_area tag actually requires the use of
> protect_title=* tag that provides users with the human readable title of
> this area-type (note: not the "name", which may also be present). ie,
> protect_title= Indigenous Protected Areas, or Indian Reservations, or
> Terra Indigena, or Territorio Indigena, etc,.. (to borrow from the
> proposal page), or perhaps just "aboriginal_lands" as a default. The
> protect_class groups the area-types of broadly similar purpose and/or
> level of protection out of what could be hundreds of variously titled
> protected-area-types around the world. Future archaeologists should be
> pleased.
>
> But although I don't buy your "numbers are bad" argument - nevertheless,
> having read the other comments on this topic I am almost persuaded that
> protected_area is not really appropriate to describe what is essentially
> a sovereign country. It might even be considered demeaning. Something
> based on administrative boundaries (which I don't have much experience
> of) might be better. I still think introducing another top-level
> "boundary= aboriginal_lands" tag is wrong. If we're not careful,
> boundary=  will wind up like amenity=* - too many darned fragmented
> values under one tag. But I'm dropping out of this particular discussion
> (... and there was much rejoicing :-))
>
> What I'm really interested in is the use of boundary=protected_area to
> accurately describe Nature-protected-areas and
> Resources-protected-areas. The "numbers are bad" assertion worries me
> and prompts a broader question: if this is "policy", does it mean that
> boundary=protected_area, and protect_class=* tags are doomed in OSM?
> Have we found the covert reason why carto still doesn't render it,
> despite the fact that it could be rendered (at least initially) exactly
> like boundary=national_park? And despite the fact that there are 70,000
> uses  around the planet? Could we be excused for suspecting that there
> is an "OSM Establishment" who would like to see it deprecated and go
> away? OK, maybe I have a nasty suspicious mind - but I can't help
> wondering. If true, could someone please come clean and just tell us to
> stop using it (and tell us what else to use)?
>
> I'm also wondering (an even broader question) at the justification for
> making a decision like this (the approval of boundary=aboriginal_lands)
> on the basis of 20 or so votes (so far, hopefully more to come)  mostly
> from involved and passionate supporters of the proposal out of the
> hundreds of thousands in the OSM community. Where are the OSM'ers who
> originally created the boundary=protected_area proposal and got it
> approved. Have they voted? And likewise for all the mappers responsible
> for the 70,000 uses? Have we had any involvement from South American
> mappers, where there seem to be a lot of protect_class=24 uses? This is
> clearly a question for another time (and mailing list) and it may have
> come up before, but it IMHO we need a more broadly based way of deciding
> things like this.
>
> Cheers..
>
>
>
>

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

2018-11-27 Thread Daniel Koć
W dniu 28.11.2018 o 03:49, Joseph Eisenberg pisze:
> Re “Have we found the covert reason why carto still doesn't render
> [Protected areas]”
>
> No need for conspiracy theories. We simply need more contributors at
> openstreetmap-carto who are willing to volunteer their time to fix
> these issues.


It took me a lot of time and effort to compare them with nature reserves
and national parks, trying to find some common ground, so I had enough
of it for over a year... However there seems to be no clear rule to
convert, so when someone nudged me lately, I just did the rest of a
dirty work with the code and now it awaits for the comments (or approval
of some other collaborator) and, hopefully, next release. That's all story.

We really do need more coders. With ~350 open tickets there's still a
lot of work for everyone.


> See: https://github.com/gravitystorm/pull/3509 “Add rendering for
> protected_area”
> And 
> https://github.com/gravitystorm/pull/3521 “Add Aboriginal Areas”


Actual links are a bit longer :-) :

https://github.com/gravitystorm/openstreetmap-carto/pull/3509

https://github.com/gravitystorm/openstreetmap-carto/pull/3521


-- 
"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] My proposal for disputed country borders

2018-11-27 Thread Johnparis
Thanks for this, Rory. I'll add it as a comment to the active proposal (
https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries
).

I don't think the notion of "according_to" is viable unless it is
restricted to the two disputing parties. (Three-way disputes can be
simplified into three two-way disputes.)

I'll also look at your proposed tag (boundary=claimed_administrative) vs.
my proposed tag (boundary_claim=administrative). Not sure whether there's
any significant difference in implementation, but would like your thoughts
on that.

I plan to rethink my proposal along these lines. One problem I now see with
my examples, for instance, is that it provides relations for SADR (de facto
and claimed) and MA (de facto and claimed), but not MA as seen by SADR. So
you can't draw a global map from these relations from the viewpoint of SADR
and its supporters. (You can do one from the viewpoint of MA, because SADR
doesn't exist in that world, but that's a special case.)

Finally, is there some reason you want to create a competing proposal? I
don't have any knowledge of two competing proposals being discussed at the
same time; would they be followed by two votes? I thought the idea was to
reach consensus.

John

On Tue, Nov 27, 2018 at 10:43 PM Rory McCann  wrote:

> This is my suggestion for how to map disputed/claimed borders.
> https://wiki.openstreetmap.org/wiki/Proposed_features/ClaimedBorders
> (but I appear to have broken the wiki).
>
> This proposal is simple. Map the claimed border of a country according
> to another country as another regular {{Tag|type|boundary}} relation,
> but add {{Tag|boundary|claimed_administrative}} +
> {{Tag|claimed:admin_level||2}} (since we're nearly always dealing with
> countries) Add the regular tags for a boundary relation (e.g.
> {{Tag|ISO3166-1}}, {{Tag|name}}).
>
> Then add {{Tag|according_to:XX||yes/no}} for each country that does or
> doesn't claims this is the border of the subject country. If
> {{Tag|according_to:XX}} is missing for an object, the value should be
> assumed to be "yes" if this is {{Tag|boundary|administrative}}, and "no"
> if it's {{Tag|boundary|claimed_administrative}}.
>
> == Examples ==
>
> === Kosovo ===
>
> {{Wikipedia|en|Kosovo|text=no}} has been
> {{Wikipedia|en|
> https://en.wikipedia.org/wiki/International_recognition_of_Kosovo
>   }} recognised by about half the members of the UN, since it is de
> facto  acting as a country, it's mapped in OSM {{relation|2088990}}, as
> {{Tag|boundary|administative}}+{{Tag|admin_level||2}}. Kosovo was part
> of Serbia, which is {{relation|1741311}}, and also
> {{Tag|boundary|administative}}+{{Tag|admin_level||2}}. Serbia & Spain
> don't recognise Kosovo, so I presume they view the border of "Serbia" to
> be the land covered by {{relation|2088990}}+{{relation|1741311}}. We can
> map this by copying the Serbia relation ({{relation|1741311}}), and
> changing the members to include the larger area, then add
>
> {{Tag|type|boundary}}+{{Tag|boundary|claimed_administrative}}+{{Tag|claimed:admin_level||2}}+{{Tag|ISO3166-1||RS}}+{{Tag|according_to:RS||yes}}+{{Tag|according_to:ES||yes}}.
>
> We can add {{Tag|according_to:XK||yes}} to the Kosovo relation, since
> (IIRC) the de facto border is what the government there claims as the
> border. We can add {{Tag|according_to:RS||no}} to the Serbia relation,
> which means "This is the de facto border of Serbia, and they claim it's
> not the border, and the UK claims it is, and Mexico claims it isn't".
>
> === Crimea ===
>
> Left as an exercise for the reader.
>
> === Kashmir ===
>
> (Correct me if I'm wrong) {{Wikipedia|en|Kashmir conflict}} is mostly a
> dispute between India and Pakistan, but China has claims on some parts.
> Neither India or Pakistan control all of what they claim. (i) The de
> facto border of India, (ii) The de facto border of Pakistan (current OSM
> countries), (iii) The borders of India according to India, (iv) The
> borders of Pakistan accroding to India, (v) The borders of Pakistan
> according to Pakistan, (vi) The borders of India according to Pakistan.
>
> Each of these 6 options would be mapped with a separate relation.
>
> == Advantages ==
>
> * Copies the same logic from multipolygons, being supported by
> * 100% backwards compatible with existing scheme to map countries
> * Easily readable tags that data consumers can probably deduce.
>
> == Disadvantages ==
>
> * Creates more relations, several extra per disputed area. This could be
> unwieldy an could lead to data consistancies
>
> == Using the data ==
>
> === Rendering a Map ===
>
> To render a map of the world with the Serbian view of borders, you
> import the data with `osm2pgsql`, then run a SQL query like:
>
> DELETE FROM planet_osm_polygon WHERE boundary = 'administrative' AND
> 'admin_level'='2' AND tags->'claimed:by:RS' = 'no',
> UPDATE planet_osm_polygon SET admin_level = '2', boundary =
> 'administrative' WHERE boundary = 'claimed_administrative' AND
> 'cl

[Tagging] Named walking tracks following road

2018-11-27 Thread Graeme Fitzpatrick
Just working on some errors identified by Map Roulette as having invalid
characters in street names.

One that's come up is
https://www.openstreetmap.org/search?query=rocky%20creek%20dam#map=18/-28.63593/153.34517,
where named walking tracks follow a service road across a dam wall.

The original mapper included the track names on the road, so it's now
erroring due to the name showing as "track;track;track"

The easiest way of fixing it is probably to just take the names off the
road, & add a parallel footpath with the names included, but is there
another way?

Thanks

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


Re: [Tagging] Named walking tracks following road

2018-11-27 Thread Warin

On 28/11/18 17:05, Graeme Fitzpatrick wrote:
Just working on some errors identified by Map Roulette as having 
invalid characters in street names.


One that's come up is 
https://www.openstreetmap.org/search?query=rocky%20creek%20dam#map=18/-28.63593/153.34517, 
where named walking tracks follow a service road across a dam wall.


This comes up with a dam with no tracks in the USA.
Better off with https://www.openstreetmap.org/way/435947564
And that clearly demonstrates the problem.




The original mapper included the track names on the road, so it's now 
erroring due to the name showing as "track;track;track"


The easiest way of fixing it is probably to just take the names off 
the road, & add a parallel footpath with the names included, but is 
there another way?


Easiest?
Delete the walking track nameS from the road.

The walking tracks are all relations and they do tolerate the use of the 
road, no mater what name it has, as part of there routes.


More work
Putting a footpath in .. what evidence do you have of the footpath?
Then changing each relation to use the footpath rather than the road.
As the original mapper has not bothered neither would I.



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


Re: [Tagging] Named walking tracks following road

2018-11-27 Thread Graeme Fitzpatrick
On Wed, 28 Nov 2018 at 16:24, Warin <61sundow...@gmail.com> wrote:

> This comes up with a dam with no tracks in the USA.
> Better off with https://www.openstreetmap.org/way/435947564


Thanks - don't know how that happened?


> Easiest?
> Delete the walking track nameS from the road.
>
> The walking tracks are all relations and they do tolerate the use of the
> road, no mater what name it has, as part of there routes.
>
> More work
> Putting a footpath in .. what evidence do you have of the footpath?
> Then changing each relation to use the footpath rather than the road.
> As the original mapper has not bothered neither would I.
>

You've talked me into it! :-)

Thanks

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


Re: [Tagging] Named walking tracks following road

2018-11-27 Thread OSMDoudou
I would suggest to make a consistent edit of the area, not just solve one 
isolated MapRoulette challenge.

Other segments of the walks have the three names:
https://www.openstreetmap.org/way/435947565
https://www.openstreetmap.org/way/435947561
etc.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging