[Tagging] Using multipolygons to map bays in Alaska

[Dave Swarthout]

Since the long thread I started about multipolygons  [1
]
is sort of winding down, I thought it best to start a new one to discuss
something I've been doing since learning from that thread of the amazing
power of the multipolygon data structure. Alaska has hundreds of bays and
straits that have been added to OSM as nodes many years ago via an import
(Tiger?). The nodes contain useful information but because they're only
nodes cannot provide any visual representation of the size or extent of
bigger bays and straits. I've begun to use multipolygon relations to show
them more prominently using sections of coastline as the ways and then
drawing a connecting way across the mouth of the bay or strait to complete
the outer ring. This structure then defines the bay and when rendered it
shows up nicely on the OSM slippy map.

However, this method means that under certain circumstances some of those
ways end up as members of several multipolygons. For example, the coastline
might be part of a boundary, and in addition define a wooded or wetland
area so it might be confusing to new mappers who might be put off by the
complexities, as I was for a long time. That's one consideration. The other
is the question about using this technique to map truly large bays like
Cook Inlet. This is the reason I'm posting this question. Here is the first
paragraph of the Wikipedia entry for the Inlet:

Cook Inlet (Dena'ina: Tikahtnu) stretches 180 miles (290 km) from the Gulf
of Alaska to Anchorage in south-central Alaska. Cook Inlet branches into
the Knik Arm and Turnagain Arm at its northern end, almost surrounding
Anchorage. On its south end merges with Shelikof Strait, Stevenson
Entrance, Kennedy Entrance and Chugach Passage.

So, I could mouse along the coastline adding pieces of it to a new relation
until I have the entire Inlet surrounded, then draw a way from Elizabeth
Island on the east side to the other side to define its mouth. I copy the
tags from the existing node to the multipolygon and delete the node. But
with a water body the size of Cook Inlet, that's a lot of work. I mapped
Cook Inlet's Turnagain Arm [2
]
the other day and it involved adding 14 ways as outers. How many will a
multipolygon covering the entire Cok Inlet require?

I was thinking it would be much easier and perhaps even better to just draw
an approximate shape consisting of maybe 20 or 30 nodes, big enough to
define the area and cause it to render, but easy to draw and without
involving any multipolygons. The issue here is admittedly one I am pursuing
to get these water bodies to render in a manner proportional to their size
and I suspect that many will be against it on that basis alone. Still, I
thought it worthwhile to mention my idea here and see what you think about
it as a "shorthand" solution. Besides, I'm betting some other useful
information will issue from the discussion.

Dave

[1]
https://lists.openstreetmap.org/pipermail/tagging/2018-October/040062.html
[2] https://www.openstreetmap.org/relation/8921978#map=9/61.1074/-149.5541
-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposed features - RFC - Pipe valves

[Warin]

On 15/11/18 10:39, François Lacombe wrote:

Hi all,

The proposal about valves I was working on has reached the RFC status 
tonight

https://wiki.openstreetmap.org/wiki/Proposed_features/Pipeline_valves_proposal

Goal is to describe with better destails how pipeline=valve objects 
are built and work. We can add visible information about actuators and 
sensors as needed.


Examples are a bit limited right now, I'm waiting to take pictures of 
more domestic devices.

Feel free to add if you have some ideas.
Obviously, I think about it for hydrants and emergency inlets.

Since only pipeline=valve is concerned so far, the document won't be 
applicable for canals sluice gates but most of used keys may be used 
in those situations
Don't know if sluice gates can be properly called valves despite gate 
valves are defined in norms.


Looking forward to your comments


I had no idea what a 'globe valve' was .. wikipedia has it  ... what I 
had called 'jumper valves' as that is the bit I have replaced many times.


Probably best to have a picture to describe them .. you can use the 
wikipedia pictures such as


https://upload.wikimedia.org/wikipedia/commons/thumb/e/e5/Globe_valve_diagram.svg/220px-Globe_valve_diagram.svg.png

Not something I map, so no expertise for these.



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

[Tagging] Proposed features - RFC - Pipe valves

[François Lacombe]

Hi all,

The proposal about valves I was working on has reached the RFC status
tonight
https://wiki.openstreetmap.org/wiki/Proposed_features/Pipeline_valves_proposal

Goal is to describe with better destails how pipeline=valve objects are
built and work. We can add visible information about actuators and sensors
as needed.

Examples are a bit limited right now, I'm waiting to take pictures of more
domestic devices.
Feel free to add if you have some ideas.
Obviously, I think about it for hydrants and emergency inlets.

Since only pipeline=valve is concerned so far, the document won't be
applicable for canals sluice gates but most of used keys may be used in
those situations
Don't know if sluice gates can be properly called valves despite gate
valves are defined in norms.

Looking forward to your comments

All the best

François
___
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 14. Nov 2018, at 10:28, SelfishSeahorse  wrote:
> 
> I like your idea with 'de_jure', 'de_facto' and 'claimed' roles.


I can understand de facto and claimed, but I find de jure hard. Which law do 
you apply? There is international law, customary international law ok, but if 
the country doesn’t consent to certain ideas, e.g. doesn’t recognize the ICJ, 
or has a different idea of customary international law? There are international 
treaties, but they might contradict themselves, be disputed by one of the 
parties, not be ratified by some few countries but by the vast majority, etc. 
Somehow we will have to judge ourselves or decide which authority we recognize 
(e.g. UN/ICJ).


Cheers, Martin 
___
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 14. Nov 2018, at 00:02, Graeme Fitzpatrick  wrote:

>> And that's assuming a disputed flag doesn't cause more problems than it 
>> solves: "No, that border
>> isn't disputed, we're absolutely certain it's right." says one of the 
>> countries involved.  So now we
>> need a flag pointing out that one country disputes that it's a disputed 
>> border...
> 
> You're probably quite right there as well :-(


I would not expect it to be a problem to find out which borders are disputed, 
the disputes are generally known. A more difficult question could be people 
claiming land, where they aren’t a country, e.g. Palestine or Tibet, because in 
these cases it might be less questionable that there are significant claims, 
but there will be also many more, less known, and claimed by less people, down 
to single individuals which claim sovereignty. We would have to give workable 
and appropriate definitions where we draw the line.

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

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

[SelfishSeahorse]

On Tue, 13 Nov 2018 at 01:52, Eugene Alvin Villar  wrote:
>
> 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").

I like your idea with 'de_jure', 'de_facto' and 'claimed' roles.
However, i see the following problems:

1. 'inner' roles (and thus 'outer' roles too) are still needed in
case a country has enclaves.
2. The boundary polygon would still not hold the information which
territory is undisputed and which is disputed. You still only have an
area that includes undisputed and disputed territory.

A possible solution i see would be:

1. A new boundary:part relation (with inner and outer roles) that
only includes either the undisputed or disputed area of a country.
2. Changing the definition of the current boundary relation in a
way that these boundary:part relations (areas) can be added as members
with role 'undisputed', 'controlled' or 'claimed' to the boundary
relation.

Thus, your example above (Country A and Country B are disputing
Territory C but currently Country A controls it) would be tagged as
follows:

1. A type=boundary:part relation with the area of country A
without the disputed territory C.
2. A type=boundary:part relation with the area of country B
without the disputed territory C.
3. A type=boundary:part relation with the disputed territory C.
4. A type=boundary relation for country A with 1 as member with
role 'undisputed' and 3 as member with role 'controlled'.
5. A type=boundary relation for country B with 2 as member with
role 'undisputed' and 3 as member with role 'claimed'.

Regards
Markus

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