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

[Warin]

On 22/10/18 09:56, Graeme Fitzpatrick wrote:




On Mon, 22 Oct 2018 at 08:42, Warin <61sundow...@gmail.com 
> wrote:



I would opt for;
depreciating amenity=embassy .. as they are used for embassies,
consulates etc .. so you don't know what they are (unless it has a
detailed sub tag)
introducing amenity=diplomatic and use the sub tag diplomatic=* to
detail what it is - embassy/consulate/*


Yep, straight-forward & simple :-)



I fit in with 'simple' .

I just looked at some amenity=embassy around me .. probably added a fair 
few of them myself.

Few of them have any diplomatic=*.

So I searched on consulate general .. and got 55 with that in their 
name, so being fairly certain they are in fact consulate generals I add 
the tag diplomatic=consulate_general, 55 of them.

I'll check the others later.



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

Re: [Tagging] Another multipolygon question

[Dave Swarthout]

In reviewing the Wiki for instructions on understanding and debugging
relations, I came across this tantalizing snippet (
https://wiki.openstreetmap.org/wiki/JOSM/Advanced_editing#Relations)

"JOSM allows you to sort members, and this is recommended for some types of
relations. e.g. route relations, multipolygons,  Sorting the members
allows you to ensure the members are connected, and to locate any
unconnected ways. To sort the members click the A-Z button in the relation
editor."

Great. But what are you actually doing when you "sort the members" of a
relation? And after sorting, how does one "ensure the members are
connected"?

I've noted with dismay the lack of debugging support for relations. For
example, I will get an error message when trying to upload an edited
relation but when I ask JOSM to Zoom to the error, the display zooms out
enough to include the entire relation with no clue as the where the actual
problem is. Same thing when you ask to "jump to the next gap". Good luck on
that also. Maybe it's just me?

Understanding the relation editor is a tough chore. But IMO, a debugging
guide would be top priority on my list. Kevin, you have a concise writing
style that would probably go a long way in helping elucidate this issue. I
fully understand about time constraints (so much to do, so little time) but
maybe someday ...

Dave

PS: As for the "leaves down" argument, my goal is to get named geographic
features mapped so the OSM map of Alaska is more complete. I can't afford
to be overly concerned about getting the shoreline of a pond or lake
perfect. For one thing, it's simply not possible to trace an exact
shoreline. The closer you zoom in, the more details there are (fractal
geometry comes into play here) and the more nodes you'll need, ad
infinitum. Add to that the sheer size of Alaska with its 3,000,000 ponds
and lakes and one can get an idea of the enormity of the task. It's simply
not practical to be concerned with minutiae like tree lined shores.

On Mon, Oct 22, 2018 at 6:50 AM Kevin Kenny  wrote:

> On Sun, Oct 21, 2018 at 7:19 PM Warin <61sundow...@gmail.com> wrote:
>
>> I used the OSM diary entry to do Public Transport. Might work for you .
>> People can make comments under it .. and you can edit the first entry you
>> made to correct errors and make changes.
>> See https://www.openstreetmap.org/user/Warin61/diary/45106
>>
>> Videos are like lessons... you need to be very well prepared to present
>> them. Written stuff you can do fairly easily and review later. A
>> presentation (video/lesson) should be correct the first time around. For
>> preference .. I'd write it .. much less stress.
>>
>
> Well, of course. I've spent enough hours standing in front of a classroom
> to understand that. For me, a video script is a lot harder to write and
> present than a lesson plan or a conference talk. In front of a classroom, I
> can see whether the students are getting it, and change the pacing
> accordingly. I can't do that with a camera.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
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] Upcoming removal of power=station and power=sub_station in the standard style

[Warin]

On 22/10/18 14:17, Daniel Koć wrote:

W dniu 22.10.2018 o 05:06, Dave Swarthout pisze:

It would seem an easy fix to change all power=sub_station tags to
power=substation without an individual inspection.

I'm surprised that automated conversion is discouraged on the wiki page
in this case. Seems like simple 1:1 objects mapping. Could we make mass
edition for this scheme?


Agree it should be a 1:1 automated conversion.
Possibly the warning has been a copy and paste?
Contact with the author of the warning might be informative.


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

Re: [Tagging] Upcoming removal of power=station and power=sub_station in the standard style

[Daniel Koć]

W dniu 22.10.2018 o 05:06, Dave Swarthout pisze:
> It would seem an easy fix to change all power=sub_station tags to
> power=substation without an individual inspection.

I'm surprised that automated conversion is discouraged on the wiki page
in this case. Seems like simple 1:1 objects mapping. Could we make mass
edition for this scheme?

> I think most new mappers already use the newer tagging guidelines but
> I'm not sure what mechanism you could use to get the message out to
> all concerned.

OSM ecosystem is highly distributed, so there's no way to reach
everybody. But the last time we asked to remove landuse=farm on this
list, it worked very effective (removing ~300.000 uses in just 2 months).


-- 
"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] Upcoming removal of power=station and power=sub_station in the standard style

[Dave Swarthout]

It would seem an easy fix to change all power=sub_station tags to
power=substation without an individual inspection. The other tag,
power=station, is much more problematical because one cannot know for sure
if that tag is correct.

I think most new mappers already use the newer tagging guidelines but I'm
not sure what mechanism you could use to get the message out to all
concerned.

Dave

On Mon, Oct 22, 2018 at 8:22 AM Daniel Koć  wrote:

> Hi,
>
> It has been noted that we still render power=station and
> power=sub_station in OSM Carto, even if they are both deprecated and
> replacement tags are much more popular by now:
>
>
> https://github.com/gravitystorm/openstreetmap-carto/issues/3305#issuecomment-414058220
>
>
> I would be happy to get rid of them eventually, but I'd like to take
> some time before doing that, because they still have some share in a
> database:
>
> - power=station - 5 016 uses -
> https://wiki.openstreetmap.org/wiki/Tag%3Apower%3Dstation
>
> - power=sub_station - 17 514 uses -
> https://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station
>
>
> Could we reduce their usage further now (or maybe even eradicate them)?
>
>
> --
> "Excuse me, I have some growing up to do" [P. Gabriel]
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
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] Hot springs and Geysers

[Joseph Eisenberg]

Some hot springs just look like
regular springs. But hot springs in volcanic areas are often sulfuric and
may have heavy mineral content. The picture on the wiki page shows an
impressive example. Others are boiling “mud pots”.

I didn’t find any uses of alternative tagging of natural=spring with
spring=hot or spring=hot_spring on Overpass Turbo, and the combinations
listed with natural=spring by Taginfo do not show anything hot-spring
related (though there may be something with less than 1000 uses)

I don’t see any tags with natural=spring and spring=geyser on overpass
turbo either.
On Mon, Oct 22, 2018 at 9:57 AM Warin <61sundow...@gmail.com> wrote:

> On 22/10/18 11:15, Graeme Fitzpatrick wrote:
>
>
>
> On Mon, 22 Oct 2018 at 09:44, Joseph Eisenberg 
> wrote:
>
>> There are now over 500 hot springs mapped with natural=hot_spring. The
>> tag was proposed way back in 2008 but the proposal was never approved.
>> Wiki:
>> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dhot_spring
>> Original proposal:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring
>>
>
> Yep, sounds like a good idea
>
>
>>
>> Some people have suggested tagging hot springs with natural=spring and a
>> spring=hot subtag, but hot springs have a quite different geological origin
>> and cultural significance. The wiki page for natural=spring has a link to
>> hot spring:
>> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dspring
>>
>
> Agree that hot spring & spring=hot are different
>
>
> I have seen both 'natural cold springs' and 'natural hot springs'.
> To me there is enough variation in appearance of 'natural cold springs' to
> encompass 'natural hot springs'.
> The only difference between the two is the temperature.
> ___
> 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] Upcoming removal of power=station and power=sub_station in the standard style

[Daniel Koć]

Hi,

It has been noted that we still render power=station and
power=sub_station in OSM Carto, even if they are both deprecated and
replacement tags are much more popular by now:

https://github.com/gravitystorm/openstreetmap-carto/issues/3305#issuecomment-414058220


I would be happy to get rid of them eventually, but I'd like to take
some time before doing that, because they still have some share in a
database:

- power=station - 5 016 uses -
https://wiki.openstreetmap.org/wiki/Tag%3Apower%3Dstation

- power=sub_station - 17 514 uses -
https://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station


Could we reduce their usage further now (or maybe even eradicate them)?


-- 
"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] Hot springs and Geysers

[Warin]

On 22/10/18 11:15, Graeme Fitzpatrick wrote:



On Mon, 22 Oct 2018 at 09:44, Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> wrote:


There are now over 500 hot springs mapped with natural=hot_spring.
The tag was proposed way back in 2008 but the proposal was never
approved. Wiki:
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dhot_spring
Original proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring


Yep, sounds like a good idea


Some people have suggested tagging hot springs with natural=spring
and a spring=hot subtag, but hot springs have a quite different
geological origin and cultural significance. The wiki page for
natural=spring has a link to hot spring:
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dspring


Agree that hot spring & spring=hot are different


I have seen both 'natural cold springs' and 'natural hot springs'.
To me there is enough variation in appearance of 'natural cold springs' 
to encompass 'natural hot springs'.

The only difference between the two is the temperature.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hot springs and Geysers

[Graeme Fitzpatrick]

On Mon, 22 Oct 2018 at 09:44, Joseph Eisenberg 
wrote:

> There are now over 500 hot springs mapped with natural=hot_spring. The tag
> was proposed way back in 2008 but the proposal was never approved. Wiki:
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dhot_spring
> Original proposal:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring
>

Yep, sounds like a good idea


>
> Some people have suggested tagging hot springs with natural=spring and a
> spring=hot subtag, but hot springs have a quite different geological origin
> and cultural significance. The wiki page for natural=spring has a link to
> hot spring:
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dspring
>

Agree that hot spring & spring=hot are different

>
> Geysers are also tagged natural=geyser. They could be considered a type of
> spring, but they are also similar to a fumarole or volcanic vent, and I
> would be quite surprised to see a geyser mapped as a “spring”
> Wiki:
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dgeyser
>

Notice that they also suggested using hot spring for mud. I would think
that bubbling mud puddles would be a different thing again?

>
> Thoughts on these tags? If natural=hot_springbkeeps climbing in use, we
> could start rendering it on the Openstreetmap-Carto style (“standard
> layer”) soon, if there is agreement on the tagging.
>

Thanks

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

Re: [Tagging] Another multipolygon question

[Kevin Kenny]

On Sun, Oct 21, 2018 at 7:19 PM Warin <61sundow...@gmail.com> wrote:

> I used the OSM diary entry to do Public Transport. Might work for you .
> People can make comments under it .. and you can edit the first entry you
> made to correct errors and make changes.
> See https://www.openstreetmap.org/user/Warin61/diary/45106
>
> Videos are like lessons... you need to be very well prepared to present
> them. Written stuff you can do fairly easily and review later. A
> presentation (video/lesson) should be correct the first time around. For
> preference .. I'd write it .. much less stress.
>

Well, of course. I've spent enough hours standing in front of a classroom
to understand that. For me, a video script is a lot harder to write and
present than a lesson plan or a conference talk. In front of a classroom, I
can see whether the students are getting it, and change the pacing
accordingly. I can't do that with a camera.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Power=cable for low voltage lines?

[Kevin Kenny]

On Sun, Oct 21, 2018 at 2:49 PM Paul Allen  wrote:

> We shouldn't be asking mappers to guess if it's a line, a minor_line or a
> cable before they can map anything.  Those distinctions are
> refinements that can be added later if further information becomes
> available.
>

Thank you for continuing to point this out.

I'm a hiker, and a large part of my OSM work is to support that activity.

When I map a power line, it's because I encounter one running through the
back country, and those things are important landmarks for hikers. I record
a power line in my field notes. even if I haven't followed it. When I get
home, I may well map what I can see of it on orthoimages. I think that many
of these are subtransmission lines, likely 69 kV, with the occasional 115
kV line thrown in for good measure. But I'm not sure - and I shouldn't have
to research what the voltage is, whether the conductors are insulated or
not, or what the power grid topology is, before I can map that "there are
overhead conductors, and (wooden/steel) (poles/H-frames/towers) visible in
the field here." If I have to do any kind of research before I can begin to
map an object that I can see with my own eyeballs in the field, something's
wrong with the model.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Hot springs and Geysers

[Joseph Eisenberg]

There are now over 500 hot springs mapped with natural=hot_spring. The tag
was proposed way back in 2008 but the proposal was never approved. Wiki:
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dhot_spring
Original proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring

Some people have suggested tagging hot springs with natural=spring and a
spring=hot subtag, but hot springs have a quite different geological origin
and cultural significance. The wiki page for natural=spring has a link to
hot spring:
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dspring

Geysers are also tagged natural=geyser. They could be considered a type of
spring, but they are also similar to a fumarole or volcanic vent, and I
would be quite surprised to see a geyser mapped as a “spring”
Wiki:
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dgeyser

Thoughts on these tags? If natural=hot_springbkeeps climbing in use, we
could start rendering it on the Openstreetmap-Carto style (“standard
layer”) soon, if there is agreement on the tagging.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Another multipolygon question

[Warin]

On 22/10/18 09:52, Kevin Kenny wrote:
On Sun, Oct 21, 2018 at 7:34 AM bkil +a...@gmail.com > wrote:


It seems many would find a short video tutorial depicting these
steps very handy. Would you mind sharing on Bitchute or on some
other video hosting site?


On Sun, Oct 21, 2018 at 9:00 AM Dave Swarthout 
mailto:daveswarth...@gmail.com>> wrote:


I was wishing that someone would write a short tutorial about
relations, the various concepts about tagging them, and problem
solving when something goes wrong with one. I have been unable to
understand with any degree of certainty how and why we create
them, which is the reason I started this thread and contributed to
the other one about tagging groups of lakes. The Wiki is helpful
but leaves out a lot of details. A tutorial, video or otherwise,
would be extremely helpful.


On Sun, Oct 21, 2018 at 1:24 PM Mateusz Konieczny 
mailto:matkoni...@tutanota.com>> wrote:


Maybe improving wiki would be a good idea as the first [step].

I find that video tutorials don't often fit my learning style, so I 
don't often use them and have never made one. Moreover, I'm an old man 
and somewhat set in my ways. Nevertheless, they seem to be demanded, 
and if nobody else steps forward, perhaps it will be possible to teach 
this old dog that new trick.  I'd be willing to take a whack at a 
written tutorial, but can't promise any particular time frame. Just at 
the moment, I'm chronically busy.


When you want something done, ask a busy person.


The right place might be the Wiki, but I've two reservations. First, 
I've simply burnt my fingers too many times when touching a Wikipedia 
page. Perhaps this community is a trifle less fiery? Second, what I've 
seen on OSM's Wiki (as well as Wikipedia and others) is that editors 
jump in to add details that make the presentation more "correct," but 
less approachable to a newcomer. For an introductory tutorial, this 
drift is disastrous, because introductory material frequently is in 
the form of a "lie to children" 
https://en.wikipedia.org/wiki/Lie-to-children that is not techinically 
accurate, but provides enough of a mental model to do simple things 
and prepares the mind to accept a more complete explanation later.


I used the OSM diary entry to do Public Transport. Might work for you . 
People can make comments under it .. and you can edit the first entry 
you made to correct errors and make changes.

See https://www.openstreetmap.org/user/Warin61/diary/45106

Videos are like lessons... you need to be very well prepared to present 
them. Written stuff you can do fairly easily and review later. A 
presentation (video/lesson) should be correct the first time around. For 
preference .. I'd write it .. much less stress.


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

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

[Johnparis]

The ID preset is a separate issue; presumably this would be easily changed
by the ID developer once the tag is agreed.

The "diplomatic" subtag already exists under amenity=embassy, so creating a
top-level amenity=diplomatic suits the logic side of my brain, but I don't
feel strongly about this. Both Warin's and Martin's arguments make sense to
me.

In either case, all the consulates would need to be retagged (which I think
is a good idea). So the only question is whether to leave embassies as
separate animals. Either way the *current usage* of amenity=embassy (as
documented in the wiki) would need an overhaul, so perhaps a new tag would
make things clearer.

I guess this means I am leaning towards Warin's argument. There are only
445 objects tagged amenity=embassy (if I read Taginfo correctly) so this
would be pretty simple.

On Mon, Oct 22, 2018 at 12:55 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> As a new mapper, I would not have though to type “diplomatic” when
> searching for a tag for an embassy or consulate. It’s nice if mappers can
> just type “embassy” or “consulate” into the ID editor and have it pop up.
>
> So I like amenity=consulate
> On Mon, Oct 22, 2018 at 7:42 AM Warin <61sundow...@gmail.com> wrote:
>
>> On 22/10/18 09:09, Martin Koppenhoefer wrote:
>>
>> >
>> > sent from a phone
>> >
>> >> On 21. Oct 2018, at 19:20, Johnparis  wrote:
>> >>
>> >> Question : there is existing tagging for such places, specifically
>> >>
>> >> amenity=embassy + diplomatic=consulate
>> >>
>> >> Frankly, I have never been happy with this tagging because a consulate
>> isn't really a subset of an embassy. It's a different sort of animal, but
>> related. Same genus, different species if you will.
>> >
>> > I agree. I am fine with the proposed tagging by Alan.
>>
>> The proposed addition of amenity=consulate then conflicts with the
>> present definition of amenity=embassy - both would be available to tag a
>> consulate!!!
>>
>> >
>> > Shifting both, embassies and consulates under a diplomatic main key
>> would require retagging of both, embassies and consulates, but the
>> embassies are already tagged ok.
>>
>> At present all embassies and consulates can be and at least some are
>> tagged as amenity=embassy!
>> There is no distinction with the present OSM wiki definition of
>> amenity=embassy.
>>
>> >
>> > Also from a practical point of view, it is faster to type one tag than
>> two.
>>
>> Certainly. Faster again to type nothing. Mappers who want to add detail
>> will do so.
>>
>> > If a map renderer doesn’t want to distinguish between the two, it can
>> use the bare amenity=diplomatic as long as people are using it together
>> with diplomatic=passport_check or something like this (think
>> tourism=information), and will have to look for diplomatic=embassy as well,
>> so they could in the first place change their rule to “amenity is embassy
>> or consulate”, and be future proof :)
>>
>> That would require typing of more than one tag.
>> Do you  want fast?
>> Then you will need one tag that says all you want ... one tag for a
>> consulate that does vias, another tag for a consulate that does not do
>> visas .. etc etc..
>>
>> Reality: more than one tag would be required to have a system that is not
>> litered with one tags that do so much detail.
>>
>> ---
>> I would opt for;
>> depreciating amenity=embassy .. as they are used for embassies,
>> consulates etc .. so you don't know what they are (unless it has a detailed
>> sub tag)
>> introducing amenity=diplomatic and use the sub tag diplomatic=* to detail
>> what it is - embassy/consulate/*
>>
>>
>>
>>
>> ___
>> 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 - (consulate)

[Warin]

That should be possible - it would come up with both tags - 
amenity=diplomatic with diplomatic=embassy, or amenity=diplomatic with 
diplomatic=consulate


If you type 'tennis' what does ID come up with? sport=tennis with a 
selection of leisure=pitch, or something=sports_centre ..


On 22/10/18 09:54, Joseph Eisenberg wrote:
As a new mapper, I would not have though to type “diplomatic” when 
searching for a tag for an embassy or consulate. It’s nice if mappers 
can just type “embassy” or “consulate” into the ID editor and have it 
pop up.


So I like amenity=consulate
On Mon, Oct 22, 2018 at 7:42 AM Warin <61sundow...@gmail.com 
> wrote:


On 22/10/18 09:09, Martin Koppenhoefer wrote:

>
> sent from a phone
>
>> On 21. Oct 2018, at 19:20, Johnparis mailto:ok...@johnfreed.com>> wrote:
>>
>> Question : there is existing tagging for such places, specifically
>>
>> amenity=embassy + diplomatic=consulate
>>
>> Frankly, I have never been happy with this tagging because a
consulate isn't really a subset of an embassy. It's a different
sort of animal, but related. Same genus, different species if you
will.
>
> I agree. I am fine with the proposed tagging by Alan.

The proposed addition of amenity=consulate then conflicts with the
present definition of amenity=embassy - both would be available to
tag a consulate!!!

>
> Shifting both, embassies and consulates under a diplomatic main
key would require retagging of both, embassies and consulates, but
the embassies are already tagged ok.

At present all embassies and consulates can be and at least some
are tagged as amenity=embassy!
There is no distinction with the present OSM wiki definition of
amenity=embassy.

>
> Also from a practical point of view, it is faster to type one
tag than two.

Certainly. Faster again to type nothing. Mappers who want to add
detail will do so.

> If a map renderer doesn’t want to distinguish between the two,
it can use the bare amenity=diplomatic as long as people are using
it together with diplomatic=passport_check or something like this
(think tourism=information), and will have to look for
diplomatic=embassy as well, so they could in the first place
change their rule to “amenity is embassy or consulate”, and be
future proof :)

That would require typing of more than one tag.
Do you  want fast?
Then you will need one tag that says all you want ... one tag for
a consulate that does vias, another tag for a consulate that does
not do visas .. etc etc..

Reality: more than one tag would be required to have a system that
is not litered with one tags that do so much detail.

---
I would opt for;
depreciating amenity=embassy .. as they are used for embassies,
consulates etc .. so you don't know what they are (unless it has a
detailed sub tag)
introducing amenity=diplomatic and use the sub tag diplomatic=* to
detail what it is - embassy/consulate/*




___
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 - (consulate)

[Graeme Fitzpatrick]

On Mon, 22 Oct 2018 at 08:42, Warin <61sundow...@gmail.com> wrote:

>
> I would opt for;
> depreciating amenity=embassy .. as they are used for embassies, consulates
> etc .. so you don't know what they are (unless it has a detailed sub tag)
> introducing amenity=diplomatic and use the sub tag diplomatic=* to detail
> what it is - embassy/consulate/*
>

Yep, straight-forward & simple :-)

Thanks

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

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

[Joseph Eisenberg]

As a new mapper, I would not have though to type “diplomatic” when
searching for a tag for an embassy or consulate. It’s nice if mappers can
just type “embassy” or “consulate” into the ID editor and have it pop up.

So I like amenity=consulate
On Mon, Oct 22, 2018 at 7:42 AM Warin <61sundow...@gmail.com> wrote:

> On 22/10/18 09:09, Martin Koppenhoefer wrote:
>
> >
> > sent from a phone
> >
> >> On 21. Oct 2018, at 19:20, Johnparis  wrote:
> >>
> >> Question : there is existing tagging for such places, specifically
> >>
> >> amenity=embassy + diplomatic=consulate
> >>
> >> Frankly, I have never been happy with this tagging because a consulate
> isn't really a subset of an embassy. It's a different sort of animal, but
> related. Same genus, different species if you will.
> >
> > I agree. I am fine with the proposed tagging by Alan.
>
> The proposed addition of amenity=consulate then conflicts with the present
> definition of amenity=embassy - both would be available to tag a
> consulate!!!
>
> >
> > Shifting both, embassies and consulates under a diplomatic main key
> would require retagging of both, embassies and consulates, but the
> embassies are already tagged ok.
>
> At present all embassies and consulates can be and at least some are
> tagged as amenity=embassy!
> There is no distinction with the present OSM wiki definition of
> amenity=embassy.
>
> >
> > Also from a practical point of view, it is faster to type one tag than
> two.
>
> Certainly. Faster again to type nothing. Mappers who want to add detail
> will do so.
>
> > If a map renderer doesn’t want to distinguish between the two, it can
> use the bare amenity=diplomatic as long as people are using it together
> with diplomatic=passport_check or something like this (think
> tourism=information), and will have to look for diplomatic=embassy as well,
> so they could in the first place change their rule to “amenity is embassy
> or consulate”, and be future proof :)
>
> That would require typing of more than one tag.
> Do you  want fast?
> Then you will need one tag that says all you want ... one tag for a
> consulate that does vias, another tag for a consulate that does not do
> visas .. etc etc..
>
> Reality: more than one tag would be required to have a system that is not
> litered with one tags that do so much detail.
>
> ---
> I would opt for;
> depreciating amenity=embassy .. as they are used for embassies, consulates
> etc .. so you don't know what they are (unless it has a detailed sub tag)
> introducing amenity=diplomatic and use the sub tag diplomatic=* to detail
> what it is - embassy/consulate/*
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Another multipolygon question

[Kevin Kenny]

On Sun, Oct 21, 2018 at 7:34 AM bkil  wrote:

> It seems many would find a short video tutorial depicting these steps very
> handy. Would you mind sharing on Bitchute or on some other video hosting
> site?
>

On Sun, Oct 21, 2018 at 9:00 AM Dave Swarthout 
wrote:

> I was wishing that someone would write a short tutorial about relations,
> the various concepts about tagging them, and problem solving when something
> goes wrong with one. I have been unable to understand with any degree of
> certainty how and why we create them, which is the reason I started this
> thread and contributed to the other one about tagging groups of lakes. The
> Wiki is helpful but leaves out a lot of details. A tutorial, video or
> otherwise, would be extremely helpful.
>

On Sun, Oct 21, 2018 at 1:24 PM Mateusz Konieczny 
wrote:

> Maybe improving wiki would be a good idea as the first [step].
>

I find that video tutorials don't often fit my learning style, so I don't
often use them and have never made one. Moreover, I'm an old man and
somewhat set in my ways. Nevertheless, they seem to be demanded, and if
nobody else steps forward, perhaps it will be possible to teach this old
dog that new trick.  I'd be willing to take a whack at a written tutorial,
but can't promise any particular time frame. Just at the moment, I'm
chronically busy.

The right place might be the Wiki, but I've two reservations. First, I've
simply burnt my fingers too many times when touching a Wikipedia page.
Perhaps this community is a trifle less fiery? Second, what I've seen on
OSM's Wiki (as well as Wikipedia and others) is that editors jump in to add
details that make the presentation more "correct," but less approachable to
a newcomer. For an introductory tutorial, this drift is disastrous, because
introductory material frequently is in the form of a "lie to children"
https://en.wikipedia.org/wiki/Lie-to-children that is not techinically
accurate, but provides enough of a mental model to do simple things and
prepares the mind to accept a more complete explanation later.

One thing that I will surely not be able to accomplish is to ferret out all
the obsolete and misleading information about relations that there is on
the Wiki. The community has had a complex history of groping toward a
theory of relations as it stands today, with several false paths along the
way. For example, I'm pretty sure that there are still Wiki pages out there
advising to place the tags that belong to a multipolygon on the (presumed
unique) outer ring. Moreover, there is bound to be similar groping in the
future as we grapple with representing ever more complex things, e.g.,
"traffic must stop at this intersection, except for right-turning traffic
in the rightmost lane, which need only give way to conflicting traffic," or
"this parking field is exclusively for the use of these three stores, all
of which are some distance down the street, not contiguous with it."

Nevertheless, there are particular relations that are surrounded by
considerably less remaining controversy and supported by extensive usage.
Among these are multipolygons, administrative boundaries (really a special
case of multipolygons, but we got there by a different path), waterways
(again, a special case of multipolygons, and this time, multipolygons
provide an acceptable alternative), and routes (bus, road, hiking, cycling,
etc.)  A tutorial or series of tutorials could certainly cover these
relations and leave the fine details, about which we quite rightly love to
argue, to a more advanced student.

I'm certainly unable to create such a help page or tutorial but someone
> with more experience should. I use relations often but when one develops an
> error, I'm usually hard pressed to fix it. As OSM becomes ever more
> sophisticated the learning curve gets steeper and mappers, especially
> beginners, will make tons of errors when using relations and won't have any
> idea how to go about fixing them.
>

 If I were to take on this task (again, no guarantees about the time
frame), I could certainly address this issue with JOSM (and possibly
Meerkartor). I surely do not know Potlatch2, iD, or any other tool well
enough to manage anything but the simplest of relations in it, nor do I see
obvious things in the UI that would do what I need. It may well be
limitations of the tools, rather than limitations of knowledge and
training, that make people assert that relations are unmaintainable or that
drawing complex boundaries twice is easier than creating multipolygons with
shared ways. That last statement, however, may be nothing but a base libel
based on ignorance. In that case, I'm more than willing to be enlighened.
It would occasionally be handy to be able to make a quick change to a
multipolygon when I'm away from a machine that has my preferred tools and
simply working in a browser.
___
Tagging mailing list
Tagging@openstreetmap.org

Re: [Tagging] Another multipolygon question

[Kevin Kenny]

On Sun, Oct 21, 2018 at 6:46 PM Warin <61sundow...@gmail.com> wrote:

> Err .. in some places .. 'leaves down' does not occur :)
>

Yes. However, the fact that "leaves down" images are needed in *those*
particular places to distinguish forest from water strongly suggests that
there isn't another area in between the two.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Another multipolygon question

[Warin]

Err .. in some places .. 'leaves down' does not occur :)


On 22/10/18 04:59, Kevin Kenny wrote:
I'm somewhat familiar with a couple of places that Alaska Dave has 
mapped, and they're the sort of places where the shoreline must be 
mapped from winter, 'leaves down' aerials, because otherwise the 
shoreline is obscured by overhanging trees and matted aquatic vegetation.


On Sun, Oct 21, 2018, 13:42 Mateusz Konieczny > wrote:


Is forest starting immediately on the water edge or is there a
beach/marsh/whatever between
water and forest?

With shoreline as border of both water and forest it is OK to
reuse it, if there is - even
currently unmapped - feature between them then reusing ways is
only going to make
life of future mappers more irritating.

20. Oct 2018 11:38 by daveswarth...@gmail.com
:

Another situation that occurs quite frequently in my mapping
(in Alaska especially), is when an island defined by
natural=coastline is also covered right to the water with
natural=wood. Usually, I duplicate the coastline, shrink it a
bit, and then tag it with natural=wood. But yesterday I tried
something new, new for me anyway, and that was to create a
single-member multipolygon from the coastline way and then tag
the resultant relation with natural=wood in order to reduce
the number of nodes used. I was pleased that JOSM didn't
complain and that the island seemed to render okay but I'm not
sure this is a legitimate procedure.
,
The island is at 58.56588, -152.59579 and the relation ID=8828482

What do you think is the best approach to handle this situation?

Dave

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



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

[Warin]

On 22/10/18 09:09, Martin Koppenhoefer wrote:



sent from a phone


On 21. Oct 2018, at 19:20, Johnparis  wrote:

Question : there is existing tagging for such places, specifically

amenity=embassy + diplomatic=consulate

Frankly, I have never been happy with this tagging because a consulate isn't 
really a subset of an embassy. It's a different sort of animal, but related. 
Same genus, different species if you will.


I agree. I am fine with the proposed tagging by Alan.


The proposed addition of amenity=consulate then conflicts with the present 
definition of amenity=embassy - both would be available to tag a consulate!!!



Shifting both, embassies and consulates under a diplomatic main key would 
require retagging of both, embassies and consulates, but the embassies are 
already tagged ok.


At present all embassies and consulates can be and at least some are tagged as 
amenity=embassy!
There is no distinction with the present OSM wiki definition of amenity=embassy.



Also from a practical point of view, it is faster to type one tag than two.


Certainly. Faster again to type nothing. Mappers who want to add detail will do 
so.


If a map renderer doesn’t want to distinguish between the two, it can use the 
bare amenity=diplomatic as long as people are using it together with 
diplomatic=passport_check or something like this (think tourism=information), 
and will have to look for diplomatic=embassy as well, so they could in the 
first place change their rule to “amenity is embassy or consulate”, and be 
future proof :)


That would require typing of more than one tag.
Do you  want fast?
Then you will need one tag that says all you want ... one tag for a consulate 
that does vias, another tag for a consulate that does not do visas .. etc etc..

Reality: more than one tag would be required to have a system that is not 
litered with one tags that do so much detail.

---
I would opt for;
depreciating amenity=embassy .. as they are used for embassies, consulates etc 
.. so you don't know what they are (unless it has a detailed sub tag)
introducing amenity=diplomatic and use the sub tag diplomatic=* to detail what 
it is - embassy/consulate/*




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

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

[Martin Koppenhoefer]

sent from a phone

> On 21. Oct 2018, at 19:20, Johnparis  wrote:
> 
> Question : there is existing tagging for such places, specifically
> 
> amenity=embassy + diplomatic=consulate
> 
> Frankly, I have never been happy with this tagging because a consulate isn't 
> really a subset of an embassy. It's a different sort of animal, but related. 
> Same genus, different species if you will.


I agree. I am fine with the proposed tagging by Alan.

Shifting both, embassies and consulates under a diplomatic main key would 
require retagging of both, embassies and consulates, but the embassies are 
already tagged ok.

Also from a practical point of view, it is faster to type one tag than two.
If a map renderer doesn’t want to distinguish between the two, it can use the 
bare amenity=diplomatic as long as people are using it together with 
diplomatic=passport_check or something like this (think tourism=information), 
and will have to look for diplomatic=embassy as well, so they could in the 
first place change their rule to “amenity is embassy or consulate”, and be 
future proof :)


Cheers,
Martin



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

Re: [Tagging] Another multipolygon question

[Martin Koppenhoefer]

sent from a phone

> On 21. Oct 2018, at 13:50, bkil  wrote:
> 
> I've seen many usages of tagging the area as desired (restaurant, playground, 
> etc.) and then only adding the extra tag barrier=fence on it to mean that the 
> area is surrounded by a fence. It renders perfectly, although I'm not sure if 
> this is a preferred notation, as it is not discussed on the wiki.


there is a property, fenced=yes, which can be added to a fenced area. For 
barrier=fence the object is expected to be a linear way (could be closed).

The fenced=yes property is currently declared deprecated by the wiki.

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

Re: [Tagging] Another multipolygon question

[Graeme Fitzpatrick]

On Mon, 22 Oct 2018 at 03:24, Mateusz Konieczny 
wrote:

> Can you get example of specific problems that you encountered
>

As mentioned once before, I'm with Dave! :-)

Please start with the absolute basics - when & why should you use a
relation, then how do you actually do it.

Thanks

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

Re: [Tagging] Power=cable for low voltage lines?

[Paul Allen]

On Sun, Oct 21, 2018 at 7:08 PM François Lacombe 
wrote:

>
> Agree with Marc marc, the best situation is power=line which can be
> completed with other tags to give more precise and useful data.
>

+1

Without fully knowing all the ramifications I'd guess the line/cable
distinction can be subsumed into
this.  It's not always easy to see (not with my eyesight, anyway) if it's
bare line, insulated cable or
sheathed line that isn't considered to be an insulated.  We shouldn't be
asking mappers to guess
if it's a line, a minor_line or a cable before they can map anything.
Those distinctions are
refinements that can be added later if further information becomes
available.

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

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

[Jerry Clough - OSM]

  
It looks as though the key in use is diplomatic in conjunction with 
amenity=embassy.
 
There are several mapped in the Brazilian city of Curitiba. The reason I'm 
aware of these was that a friend was the Polish consul during the early 1990s.
 
Jerry
On 21/10/2018 18:01, Allan Mustard wrote:
  
 

https://wiki.openstreetmap.org/wiki/Proposed_features/Consulate
 
Consular representation of a foreign country in a host country as defined by 
the Vienna Convention on Consular Relations
 

 
 

 
 

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

Re: [Tagging] Power=cable for low voltage lines?

[François Lacombe]

Le dim. 21 oct. 2018 à 19:13, Mateusz Konieczny  a
écrit :

> The same may be said about exactly any classification. Major power lines
> and minor ones
>
> categorization is not unique to OSM tagging, the same split is present in
> other maps.
>
Always doing so doesn't make data objective nor an acceptable practice.

Le dim. 21 oct. 2018 à 19:25, Mateusz Konieczny  a
écrit :

> height=* then ?
>
> Impossible to do in aerial-based mapping, unreasonable even for ground
> survey mapping.
>
There is also open data.
For instance, osmose currently propose to complete all transmission towers
in France with this file
https://opendata.reseaux-energies.fr/explore/dataset/pylones-rte/information/?disjunctive.etat=-hauteur_pylone

Heights are going from 8m to >100m
Nevertheless, height is attached to support, not the line itself.

Le dim. 21 oct. 2018 à 19:43, Mateusz Konieczny  a
écrit :

> 20. Oct 2018 09:03 by fl.infosrese...@gmail.com:
> You may disagree with it or considered it as unimportant but there is at
> least one other
>
> pro argument - ease of mapping for people not interested in mapping
> details like
>
> exact height or voltage.
>
People aren't forced to produce completed object at first time they map
them.
People may be annoyed with such a question "is the line is minor or just a
line?" if they're not interested.
That's why we are looking for a default meaning for unqualified power lines
as to encourage knowledgeable people to improve their tagging.

Mappers doesn't always use bare JOSM to map, other useful tools help them
to produce data at a high quality level.

Agree with Marc marc, the best situation is power=line which can be
completed with other tags to give more precise and useful data.

All the best

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

Re: [Tagging] Another multipolygon question

[Kevin Kenny]

I'm somewhat familiar with a couple of places that Alaska Dave has mapped,
and they're the sort of places where the shoreline must be mapped from
winter, 'leaves down' aerials, because otherwise the shoreline is obscured
by overhanging trees and matted aquatic vegetation.

On Sun, Oct 21, 2018, 13:42 Mateusz Konieczny 
wrote:

> Is forest starting immediately on the water edge or is there a
> beach/marsh/whatever between
> water and forest?
>
> With shoreline as border of both water and forest it is OK to reuse it, if
> there is - even
> currently unmapped - feature between them then reusing ways is only going
> to make
> life of future mappers more irritating.
>
> 20. Oct 2018 11:38 by daveswarth...@gmail.com:
>
> Another situation that occurs quite frequently in my mapping (in Alaska
> especially), is when an island defined by natural=coastline is also covered
> right to the water with natural=wood. Usually, I duplicate the coastline,
> shrink it a bit, and then tag it with natural=wood. But yesterday I tried
> something new, new for me anyway, and that was to create a single-member
> multipolygon from the coastline way and then tag the resultant relation
> with natural=wood in order to reduce the number of nodes used. I was
> pleased that JOSM didn't complain and that the island seemed to render okay
> but I'm not sure this is a legitimate procedure.
> ,
> The island is at 58.56588, -152.59579 and the relation ID=8828482
>
> What do you think is the best approach to handle this situation?
>
> Dave
>
> --
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Power=cable for low voltage lines?

[marc marc]

Le 21. 10. 18 à 12:50, Joseph Eisenberg a écrit :
> Aren’t major lines usually part of the longer-distance transmission 
> system, and minor lines are local distribution? Like highway=primary vs 
> highway=residential?
> 
> That seems like a useful and important distinction, 

well, as we can see with this thread, the diff betwen line
and minor_line is, depending of the mapper :
- the size of the tower (although it would make a lot more sense to tag 
a tower as major/minor instead of putting this information on the line)
- the usage transmission > distribution
- the voltage

it seems to be like landuse=forest <> natural=wood, the only information 
we can deduce is that there is a line, the rest is variable according to 
the mapper, the rest is "meaning a or meaning b or meaning c" so finally 
no meaning if you want to use the data seriously

Le 21. 10. 18 à 19:42, Mateusz Konieczny a écrit :
 > ease of mapping for people not interested in mapping  details

the ease of mapping is power=line and move all details away.
having a minor_line<>line that depends on the size of the towers
as you seem to prefer is probably not easier.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Power=cable for low voltage lines?

[Mateusz Konieczny]

20. Oct 2018 09:03 by fl.infosrese...@gmail.com 
:


>
> Le sam. 20 oct. 2018 à 04:07, Greg Troxel <> g...@lexort.com 
> > > a écrit :
>> If so, I agree, but it's been explained that this fight happened a while
>> ago and what we have now is the outcome.
>>
>
> Not exactly.> I began to contribute to OSM in 2012.> People already get used 
> to line/minor_line/cable. All those tags were well established and the only 
> pro argument was "there are too much of them, we won't change"
>




You may disagree with it or considered it as unimportant but there is at least 
one other

pro argument - ease of mapping for people not interested in mapping details like

exact height or voltage.

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

Re: [Tagging] Another multipolygon question

[Mateusz Konieczny]

Is forest starting immediately on the water edge or is there a 
beach/marsh/whatever betweenwater and forest?
With shoreline as border of both water and forest it is OK to reuse it, if 
there is - evencurrently unmapped - feature between them then reusing ways is 
only going to make 
life of future mappers more irritating.

20. Oct 2018 11:38 by daveswarth...@gmail.com :


> Another situation that occurs quite frequently in my mapping (in Alaska 
> especially), is when an island defined by natural=coastline is also covered 
> right to the water with natural=wood. Usually, I duplicate the coastline, 
> shrink it a bit, and then tag it with natural=wood. But yesterday I tried 
> something new, new for me anyway, and that was to create a single-member 
> multipolygon from the coastline way and then tag the resultant relation with 
> natural=wood in order to reduce the number of nodes used. I was pleased that 
> JOSM didn't complain and that the island seemed to render okay but I'm not 
> sure this is a legitimate procedure. 
> ,
> The island is at 58.56588, -152.59579 and the relation ID=8828482
> What do you think is the best approach to handle this situation?
> Dave
>
> -- 
> 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] Power=cable for low voltage lines?

[Mateusz Konieczny]

21. Oct 2018 14:06 by j...@liotier.org :


> > On 10/21/18 11:23 AM, François Lacombe  wrote:
> > 
>> >> >>   >> >> Le dim. 21 oct. 2018 à 
>> 09:21, Martin  Koppenhoefer <>> dieterdre...@gmail.com 
>> >> > a  écrit :>> 
>>>   
>>>   no, the argument is that this is a basic distinction which
>>>   anyone can make, without knowing about transmission,  
>>> distribution or voltage.
>>>   
>>>   Line is on poles? so it is a minor line. On towers? line.
>>> 
>>   >> >>   >> 
> 
>>   >> >> Which is not true because you find poles more  
>> massive than tiny towers.>> 
>> >> >> Big... small... minor... major what does that  
>> mean?>>   >> 
> 
> height=* then ?
>




Impossible to do in aerial-based mapping, unreasonable even for ground survey 
mapping.

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

Re: [Tagging] Another multipolygon question

[Mateusz Konieczny]

21. Oct 2018 14:58 by daveswarth...@gmail.com :


> I was wishing that someone would write a short tutorial about relations, the 
> various concepts about tagging them, and problem solving when something goes 
> wrong with one. I have been unable to understand with any degree of certainty 
> how and why we create them, which is the reason I started this thread and 
> contributed to the other one about tagging groups of lakes. 




I thought about doing something like that, but my main reason why I avoided 
that is




- I am not sure what exactly is unclear for other

- I was dubious whatever my work would be noticed by people who would need it


 

> The Wiki is helpful but leaves out a lot of details. A tutorial, video or 
> otherwise, would be extremely helpful.




Maybe improving wiki would be a good idea as the first steep.




Can you get example of specific problems that you encountered and wiki pages 
where 


you tried to dind an answer?

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

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

[Johnparis]

To answer the question from Mateusz, most consulates have a plaque outside
with the name, such as "Consulat de Mali", and they are physically separate
from the embassies even in cities (like Paris, where I live) where a
country might have both (such as the USA does).

Question : there is existing tagging for such places, specifically

amenity=embassy + diplomatic=consulate

Frankly, I have never been happy with this tagging because a consulate
isn't really a subset of an embassy. It's a different sort of animal, but
related. Same genus, different species if you will.

It would make more sense to me, if you were to make a change at the top
level, to do this:

amenity=diplomatic + diplomatic=embassy for embassies
amenity=diplomatic + diplomatic=consulate for consulates

This is more in keeping with the hierarchical structures of other tag types.

I see that "office=diplomatic" was proposed along these lines in 2010-11,
on the theory that these are more offices than amenities, but frankly I
think amenity is better, since those are supposedly things to help
tourists, which consulates, at least, are specifically aimed at.

I don't really like amenity=consulate, but I do agree that it's better than
the current amenity=embassy + diplomatic=consulate for consulates.




On Sun, Oct 21, 2018 at 7:06 PM Mateusz Konieczny 
wrote:

> "but are not embassies as defined by international law"
>
> How the difference is visible in a ground survey done by somebody who is
> not
> an international law expert?
>
>
> 21. Oct 2018 19:01 by al...@mustard.net:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Consulate
>
> Consular representation of a foreign country in a host country as defined
> by the Vienna Convention on Consular Relations
>
>
>
>
> ___
> 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] Power=cable for low voltage lines?

[Mateusz Konieczny]

21. Oct 2018 11:23 by fl.infosrese...@gmail.com 
:


> That's exactly my point: currently the necessary classification is made upon 
> subjective criterias> Big... small... minor... major what does that mean?> As 
> said things aren't so binary, what about lines which are not minor nor major?




The same may be said about exactly any classification. Major power lines and 
minor ones 


categorization is not unique to OSM tagging, the same split is present in other 
maps.





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

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

[Mateusz Konieczny]

"but are not embassies as defined by international law"
How the difference is visible in a ground survey done by somebody who is notan 
international law expert?


21. Oct 2018 19:01 by al...@mustard.net :


> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Consulate 
> 
> 
> Consular representationof a foreign country in a host country as 
> defined by the ViennaConvention on Consular Relations
> 
>
>   
> 
>
>   
> 
>
> 
>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

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

Consular representation of a foreign country in a host country as
defined by the Vienna Convention on Consular Relations




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

Re: [Tagging] Another multipolygon question

[Dave Swarthout]

I was wishing that someone would write a short tutorial about relations,
the various concepts about tagging them, and problem solving when something
goes wrong with one. I have been unable to understand with any degree of
certainty how and why we create them, which is the reason I started this
thread and contributed to the other one about tagging groups of lakes. The
Wiki is helpful but leaves out a lot of details. A tutorial, video or
otherwise, would be extremely helpful.

I'm certainly unable to create such a help page or tutorial but someone
with more experience should. I use relations often but when one develops an
error, I'm usually hard pressed to fix it. As OSM becomes ever more
sophisticated the learning curve gets steeper and mappers, especially
beginners, will make tons of errors when using relations and won't have any
idea how to go about fixing them.

Dave

On Sun, Oct 21, 2018 at 6:50 PM bkil  wrote:

> I've seen many usages of tagging the area as desired (restaurant,
> playground, etc.) and then only adding the extra tag barrier=fence on it to
> mean that the area is surrounded by a fence. It renders perfectly, although
> I'm not sure if this is a preferred notation, as it is not discussed on the
> wiki.
>
> The infobox on the right does prohibit usage on areas, but I'm not sure
> what kind of consideration went into deciding this. Jojo4u introduced this
> restriction on 2015-03-27T21:56 with comment "not defined as an area":
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag:barrier%3Dfence=1153410=1152965
>
> It was not mentioned in the original proposal:
>
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/barriers=817496
>
> However it was brought up on the talk page in 2008:
>
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/barriers#Linear_and_area_barrier_.28Add_Walls.29
>
> And anyway such documentation can become out of date, so my question is
> whether this notation is viable?
>
>
> On Sat, Oct 20, 2018 at 1:22 PM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 20. Oct 2018, at 11:38, Dave Swarthout 
>> wrote:
>> >
>> > But yesterday I tried something new, new for me anyway, and that was to
>> create a single-member multipolygon from the coastline way and then tag the
>> resultant relation with natural=wood in order to reduce the number of nodes
>> used. I was pleased that JOSM didn't complain and that the island seemed to
>> render okay but I'm not sure this is a legitimate procedure
>>
>>
>> I also do this, for example if there’s a fence but I also want to tag the
>> area it delimits. Or for buildings and things that are there, in some cases.
>>
>>
>> Cheers, Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>

-- 
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] Power=cable for low voltage lines?

[Jean-Marc Liotier]

On 10/21/18 11:23 AM, François Lacombe wrote:
Le dim. 21 oct. 2018 à 09:21, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> a écrit :



no, the argument is that this is a basic distinction which anyone
can make, without knowing about transmission, distribution or voltage.

Line is on poles? so it is a minor line. On towers? line.

Which is not true because you find poles more massive than tiny towers.

Big... small... minor... major what does that mean?


height=* then ? A bit harder to describe for the novice contributor, but 
still within reach with no specific technical skills and it adds a 
measure of objectivity to the description. cables=* is even easier. Both 
provide a beginning of importance classification, accessible with no 
domain knowledge of the electric network. Maybe that is the way forward ?


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

Re: [Tagging] Another multipolygon question

[bkil]

I've seen many usages of tagging the area as desired (restaurant,
playground, etc.) and then only adding the extra tag barrier=fence on it to
mean that the area is surrounded by a fence. It renders perfectly, although
I'm not sure if this is a preferred notation, as it is not discussed on the
wiki.

The infobox on the right does prohibit usage on areas, but I'm not sure
what kind of consideration went into deciding this. Jojo4u introduced this
restriction on 2015-03-27T21:56 with comment "not defined as an area":
https://wiki.openstreetmap.org/w/index.php?title=Tag:barrier%3Dfence=1153410=1152965

It was not mentioned in the original proposal:
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/barriers=817496

However it was brought up on the talk page in 2008:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/barriers#Linear_and_area_barrier_.28Add_Walls.29

And anyway such documentation can become out of date, so my question is
whether this notation is viable?


On Sat, Oct 20, 2018 at 1:22 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 20. Oct 2018, at 11:38, Dave Swarthout 
> wrote:
> >
> > But yesterday I tried something new, new for me anyway, and that was to
> create a single-member multipolygon from the coastline way and then tag the
> resultant relation with natural=wood in order to reduce the number of nodes
> used. I was pleased that JOSM didn't complain and that the island seemed to
> render okay but I'm not sure this is a legitimate procedure
>
>
> I also do this, for example if there’s a fence but I also want to tag the
> area it delimits. Or for buildings and things that are there, in some cases.
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Another multipolygon question

[bkil]

It seems many would find a short video tutorial depicting these steps very
handy. Would you mind sharing on Bitchute or on some other video hosting
site?

On Sun, Oct 21, 2018 at 3:26 AM Kevin Kenny  wrote:

> Works great, right up until you need to maintain it.  So, you've got
>> your "natural=wood" multipolygon sharing a way with an adjoining
>> "natural=scrub".  And then, some inconsiderate developer bulldozes his
>> way across the boundary and puts up a housing development.  Now what do
>> you do?  You can't unglue the boundary and shrink the two affected
>> areas to make room for the "landuse=residential" because there's only
>> one way.
>>
>> The only option I've found is to remove the affected section of
>> boundary from one of the multipolygons, move it to the new location,
>> create a new boundary way for the other multipolygon in the proper
>> place and add it, create a new multipolygon for the development and add
>> the relevant boundary ways to it, and then confirm that you haven't
>> broken any of the multipolygons involved.  It's painful enough that
>> it's usually faster and easier just to delete everything and re-create
>> them from scratch as ordinary closed ways.
>>
>
> I actually do edit those things pretty routinely. It involves redrawing
> only for the added ways.
>
> Draw the new closed polygon representing the landuse=residential. Make it
> a multipolygon immediately.
>
> Insert nodes at the intersections of this closed way with the existing
> ways (if you didn't draw it that way to start with). Split the old and new
> ways on the nodes. (Splitting is safe - they're multipolygons already.)
> JOSM has an 'add nodes at intersections' feature that helps with this.
>
> Edit each of the old multipolygons to replace their old boundaries with
> the new ones. That's just 'remove the old ways, insert the new ones' in the
> relation editor.
>
> Finally, delete any ways that are now unused.
>
> I can do this *lots* faster than I can redraw an irregular boundary, at
> least in JOSM. (I'm not skilled enough with iD to comment. it wasn't much
> harder in Meerkartor when I tried 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] Power=cable for low voltage lines?

[Joseph Eisenberg]

Aren’t major lines usually part of the longer-distance transmission system,
and minor lines are local distribution? Like highway=primary vs
highway=residential?

That seems like a useful and important distinction, and it usually goes
along with the difference in voltage and the heights of the things
supporting the wires.

It would be nice to have a different category for the private cables or
lines to individual buildings or between private buildings, equivalent to
highway=service, so that these could be easily filtered out from maps and
schematics of the transmission / distribution system
On Sun, Oct 21, 2018 at 6:24 PM François Lacombe 
wrote:

> Le dim. 21 oct. 2018 à 09:21, Martin Koppenhoefer 
> a écrit :
>
>>
>> > On 20. Oct 2018, at 09:03, François Lacombe 
>> wrote:
>> >
>> > We all agree on necessarily classification, but the only argument in
>> favor of line/minor_line is they are too used to change.
>>
>>
>> no, the argument is that this is a basic distinction which anyone can
>> make, without knowing about transmission, distribution or voltage.
>> Line is on poles? so it is a minor line. On towers? line.
>> This doesn’t describe what you want to know, but it describes the visual
>> prominence.
>>
>
> Which is not true because you find poles more massive than tiny towers.
>
> That's exactly my point: currently the necessary classification is made
> upon subjective criterias
> Big... small... minor... major what does that mean?
> As said things aren't so binary, what about lines which are not minor nor
> major?
>
>> ___
> 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] Power=cable for low voltage lines?

[François Lacombe]

Le dim. 21 oct. 2018 à 09:21, Martin Koppenhoefer 
a écrit :

>
> > On 20. Oct 2018, at 09:03, François Lacombe 
> wrote:
> >
> > We all agree on necessarily classification, but the only argument in
> favor of line/minor_line is they are too used to change.
>
>
> no, the argument is that this is a basic distinction which anyone can
> make, without knowing about transmission, distribution or voltage.
> Line is on poles? so it is a minor line. On towers? line.
> This doesn’t describe what you want to know, but it describes the visual
> prominence.
>

Which is not true because you find poles more massive than tiny towers.

That's exactly my point: currently the necessary classification is made
upon subjective criterias
Big... small... minor... major what does that mean?
As said things aren't so binary, what about lines which are not minor nor
major?

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

Re: [Tagging] Power=cable for low voltage lines?

[Martin Koppenhoefer]

sent from a phone

> On 20. Oct 2018, at 09:03, François Lacombe  wrote:
> 
> We all agree on necessarily classification, but the only argument in favor of 
> line/minor_line is they are too used to change.


no, the argument is that this is a basic distinction which anyone can make, 
without knowing about transmission, distribution or voltage.
Line is on poles? so it is a minor line. On towers? line.
This doesn’t describe what you want to know, but it describes the visual 
prominence.

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