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

[Warin]

On 31/10/18 12:33, Allan Mustard wrote:


Some responses to Warin:

On 10/31/2018 3:45 AM, Warin wrote:

Errr.

By combining Embassy with High Commission there is a decrease in 
information.


No information is lost. "High Commission" is an embassy by another 
name, between Commonwealth members.  The term "high commission" would 
be preserved both in the embassy=* tag and the name=* tag.

Mappers don't do sub tags well
Example;
Over 11,000 amenity=embassy
Some 4,000 diplomatic=*

Less than half the 'embassies' have the tag diplomatic, yet over 95% 
have a name tag.

So they will use the name tag (that renders) together with the
amenity=embassy tag (that renders) but they are reluctant to use the 
diplomatic tag (that does not render).


I think the same will occur to these embassy=* tags.

Another decrease in information is consulate and consult general ... 
there may be more if I dig.


The VCDR does not mention embassy. It has 'mission' and 'consular' 
but no 'embassy', nor 'high commission' etc.


As I pointed out in an earlier post, "embassy" technically and legally 
consists of the people dispatched to a foreign country on a diplomatic 
mission. By convention and in vernacular use, "embassy" is used to 
denote the physical structure of the diplomatic mission in which said 
people operate.  The VCDR is a legal document (a treaty).  It uses 
legal language.  I have provided a great deal of detail (much of which 
would be captured in the wiki, ultimately) describing the various 
flavors of diplomatic missions, which broadly speaking fall into three 
categories: embassies, consulates, and other.  If you doubt my word, 
as you seem to, please consult with your local ministry of foreign 
affairs.  If you are willing to take the word of Wikipedia, its 
article on diplomatic missions is pretty good: 
https://en.wikipedia.org/wiki/Diplomatic_mission#Naming
Then the real fun begins.  As I have read through the various 
comments and suggestions, it has occurred to me that the following 
hierarchy of tags would potentially fill the bill:


The three values/categories (embassy, consulate, other) would have 
specific subcategories.  If you wanted to do a key search in 
overpass turbo, it would still be possible. The subcategories would be


* embassy=[embassy/yes, nunciature, high_commission, 
interests_section, mission, delegation, branch_embassy]


* consulate=[consulate/yes, consulate_general, consular_agency, 
consular_office, honorary_con



The above 'consolidations' ... loose information.

How do they lose information?  All information is preserved in the 
additional tags.

Those additional tags probably won't be used, see above.


If required that consolidation can be done in rendering.

But, I think, most renders now ignore them and simply render all of 
them the same. And, I think, that will continue for quite some time.


If a render chose to distinguish between them then they can do so, 
they cannot distinguish between an embassy and a high commission if 
that information is not there.


I cannot conceive of a circumstance under which anyone would want to 
render embassies and high commissions differently.  They are different 
names for the same level of diplomatic mission (a mission covered by 
the VCDR and headed by an ambassador).  If a renderer wanted to 
distinguish them, it could be done with an IF statement testing the 
existence of the string "high_commission" in either the name=* tag or 
the embassy=* tag.  Same goes for an overpass turbo search.


If there no difference then they would be the same name.
Could be construed as the same kind of thing as the tag 
'minor_mission'.  :)


Embassies and consulate are now rendered the same, that will probably 
continue, even if they have different tags.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Allan Mustard]

On 10/31/2018 3:11 AM, Joseph Eisenberg wrote:
>
> If the consensus is that "other" sucks as an option I'm certainly
> open to other suggestions, but we need something for diplomatic
> missions headed by neither an ambassador/charge d'affaires (i.e.,
> subject to the VCDR) nor a consul (i.e., subject to the VCCR).
>
> diplomatic=minor_mission? If there's neither a consul nor an
> ambassador, it must be somehow minor ;-)
>
Nobody wants to be called "minor" in diplomacy.  Wars have been fought
over lesser insults.  If that's the only other suggestion, then my
proposal will remain "other" :-o  The head of the OSCE mission here in
Ashgabat is a former ambassador and will certainly take umbrage with me
if her mission is somehow described as "minor".
>
> if these are all exclusive, it could also be:
>
> amenity=[embassy, consulate, minor_mission]
>
I think we are past the point of calling diplomatic missions "amenity". 
We're now down to either "office=diplomatic" or "diplomatic=*"  There
has been broad consensus expressed that diplomatic missions are not
amenities.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Allan Mustard]

Some responses to Warin:

On 10/31/2018 3:45 AM, Warin wrote:
> Errr.
>
> By combining Embassy with High Commission there is a decrease in
> information.
>
No information is lost.  "High Commission" is an embassy by another
name, between Commonwealth members.  The term "high commission" would be
preserved both in the embassy=* tag and the name=* tag.
>
> The VCDR does not mention embassy. It has 'mission' and 'consular' but
> no 'embassy', nor 'high commission' etc.
>
As I pointed out in an earlier post, "embassy" technically and legally
consists of the people dispatched to a foreign country on a diplomatic
mission.  By convention and in vernacular use, "embassy" is used to
denote the physical structure of the diplomatic mission in which said
people operate.  The VCDR is a legal document (a treaty).  It uses legal
language.  I have provided a great deal of detail (much of which would
be captured in the wiki, ultimately) describing the various flavors of
diplomatic missions, which broadly speaking fall into three categories:
embassies, consulates, and other.  If you doubt my word, as you seem to,
please consult with your local ministry of foreign affairs.  If you are
willing to take the word of Wikipedia, its article on diplomatic
missions is pretty good:
https://en.wikipedia.org/wiki/Diplomatic_mission#Naming
>> Then the real fun begins.  As I have read through the various
>> comments and suggestions, it has occurred to me that the following
>> hierarchy of tags would potentially fill the bill:
>>
>> The three values/categories (embassy, consulate, other) would have
>> specific subcategories.  If you wanted to do a key search in overpass
>> turbo, it would still be possible. The subcategories would be
>>
>> * embassy=[embassy/yes, nunciature, high_commission,
>> interests_section, mission, delegation, branch_embassy]
>>
>> * consulate=[consulate/yes, consulate_general, consular_agency,
>> consular_office, honorary_con
>>
> The above 'consolidations' ... loose information.
>
How do they lose information?  All information is preserved in the
additional tags.
>
> If required that consolidation can be done in rendering.
>
> But, I think, most renders now ignore them and simply render all of
> them the same. And, I think, that will continue for quite some time.
>
> If a render chose to distinguish between them then they can do so,
> they cannot distinguish between an embassy and a high commission if
> that information is not there.
>
I cannot conceive of a circumstance under which anyone would want to
render embassies and high commissions differently.  They are different
names for the same level of diplomatic mission (a mission covered by the
VCDR and headed by an ambassador).  If a renderer wanted to distinguish
them, it could be done with an IF statement testing the existence of the
string "high_commission" in either the name=* tag or the embassy=* tag. 
Same goes for an overpass turbo search.

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

[Tagging] Public Transport Timetables Proposal RFC

[Leif Rasmussen]

Hello everyone!
I recently wrote up a proposal page for public transport schedule data.
This information would allow OpenStreetMap to store information about when
or how often certain buses or trains arrive at a platform.

https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

Please feel free to look over the page and give feedback.  I am very open
to changing the proposal, so let me know if you have any ideas for
improvements to it.
Thanks,
Leif Rasmussen
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Add telecom=* to Map Feature pages

[François Lacombe]

Hi all,

Following the approval of the Telecom local loops proposal, the telecom=*
key got 3 new values replacing several building=* and man_made=* very
particular values.

telecom=* is intended to be one of the keys used to map telecommunication
infrastructure.
https://wiki.openstreetmap.org/wiki/Key:telecom

I've created a template and added it to the Map Feature page.
https://wiki.openstreetmap.org/wiki/Template:Map_Features:telecom

Since this key is pretty new, it was convenient to use the TagList
template. We have to wait for taginfo to update to get all descriptions of
values in the table.
All keys / values descriptions have to be translated in your language if
you want to translate the telecom template itself.

Feel free to improve it as much as it can, all the best

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

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

[Warin]

On 31/10/18 04:46, Allan Mustard wrote:


Not really dropping. More like reorganizing.



Errr.

By combining Embassy with High Commission there is a decrease in 
information.


As someone who has spent hours puzzling over Maperitive's rendering 
rules, deciding how to build them so that particular categories of 
POIs will be rendered in specific ways, I am quite sensitive to the 
need for consistency and a finite number of possible permutations 
while also accommodating the need to cover every eventuality.  
Hierarchies are designed for exactly that purpose.  After much back 
and forth at this point I am proposing a hierarchy that I believe 
meets all needs without being overly complex, and which will 
accommodate the novice mapper (diplomatic=embassy, period) and the 
advanced mapper (diplomatic=embassy, embassy=interests_section, 
etc.).  And by the way, it is radically different from my original 
proposal.


diplomatic=* would become a top-level, primary tag.  It would have 
three categories: embassy, consulate, other.  If the consensus is that 
"other" sucks as an option I'm certainly open to other suggestions, 
but we need something for diplomatic missions headed by neither an 
ambassador/charge d'affaires (i.e., subject to the VCDR) nor a consul 
(i.e., subject to the VCCR).


The VCDR does not mention embassy. It has 'mission' and 'consular' but 
no 'embassy', nor 'high commission' etc.


Then the real fun begins.  As I have read through the various comments 
and suggestions, it has occurred to me that the following hierarchy of 
tags would potentially fill the bill:


The three values/categories (embassy, consulate, other) would have 
specific subcategories.  If you wanted to do a key search in overpass 
turbo, it would still be possible. The subcategories would be


* embassy=[embassy/yes, nunciature, high_commission, 
interests_section, mission, delegation, branch_embassy]


* consulate=[consulate/yes, consulate_general, consular_agency, 
consular_office, honorary_consul]




The above 'consolidations' ... loose information.

If required that consolidation can be done in rendering.

But, I think, most renders now ignore them and simply render all of them 
the same. And, I think, that will continue for quite some time.


If a render chose to distinguish between them then they can do so, they 
cannot distinguish between an embassy and a high commission if that 
information is not there.


They can combine Embassies and High Commission etc if that information 
is there.



You can see I favour keeping the longer diversified values.

--

I don't really care if the key diplomatic becomes a top level tag or not.

But the tag amenity=embassy is wrong ... so needs to be depreciated with 
something else, possibly the key diplomatic=* at the top level ...or 
amenity=diplomatic and then the sub tag diplomatic=*




Probably a vote on this subject alone is worthwhile.


Keeping it simple is a good thing.

--

Using the name values of amenity=embassy can work to determine what 
value the key diplomatic=* should have, provided the name/language has 
that information.


-

Tagging and mapping of the services offered .. I'd advise getting one 
thing done at a time, don't get distracted on the 'extras'.


Add this on that large 'todo list'  :)

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

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

[Joseph Eisenberg]

Re: “To make this work, projects like osm carto would either have to add a
column for this key to their dbs”

I don’t think this is a big problem. This year we added “advertising” as a
top-level key that is rendered for advertising=column.

It does make the code a little more complex, but so does every new feature
and subtag.

I can’t say if a new main tag would affect performance of the rendering
servers, but I don’t think it would be significant.
On Wed, Oct 31, 2018 at 3:49 AM Martin Koppenhoefer 
wrote:

>
>
> Am Di., 30. Okt. 2018 um 18:48 Uhr schrieb Allan Mustard <
> al...@mustard.net>:
>
>> Not really dropping.  More like reorganizing.  As someone who has spent
>> hours puzzling over Maperitive's rendering rules, deciding how to build
>> them so that particular categories of POIs will be rendered in specific
>> ways, I am quite sensitive to the need for consistency and a finite number
>> of possible permutations while also accommodating the need to cover every
>> eventuality.  Hierarchies are designed for exactly that purpose.  After
>> much back and forth at this point I am proposing a hierarchy that I believe
>> meets all needs without being overly complex, and which will accommodate
>> the novice mapper (diplomatic=embassy, period) and the advanced mapper
>> (diplomatic=embassy, embassy=interests_section, etc.).
>>
>> diplomatic=* would become a top-level, primary tag.  It would have three
>> categories: embassy, consulate, other.
>>
>
> to make this work, projects like osm carto would either have to add a
> column for this key to their dbs or mappers would have to add something
> like amenity=diplomatic on top of all tags (and likely it will lead to the
> second way of doing it). It would make sense, if amenity=diplomatic was
> sufficient information for a significant number of people, it doesn't make
> sense if amenity=diplomatic does not convey the required information.
>
>
>> If the consensus is that "other" sucks as an option I'm certainly open to
>> other suggestions, but we need something for diplomatic missions headed by
>> neither an ambassador/charge d'affaires (i.e., subject to the VCDR) nor a
>> consul (i.e., subject to the VCCR).
>>
>
> diplomatic=minor_mission? If there's neither a consul nor an ambassador,
> it must be somehow minor ;-)
>
>
>
>> Then the real fun begins.  As I have read through the various comments
>> and suggestions, it has occurred to me that the following hierarchy of tags
>> would potentially fill the bill:
>>
>> The three values/categories (embassy, consulate, other) would have
>> specific subcategories.  If you wanted to do a key search in overpass
>> turbo, it would still be possible. The subcategories would be
>>
>> * embassy=[embassy/yes, nunciature, high_commission, interests_section,
>> mission, delegation, branch_embassy]
>>
>> * consulate=[consulate/yes, consulate_general, consular_agency,
>> consular_office, honorary_consul]
>>
>> * other=[liaison_office, representative_office, subnational]
>>
>
> if these are all exclusive, it could also be:
>
> amenity=[embassy, consulate, minor_mission]
> diplomatic=[(embassy/yes), nunciature, high_commission,
> interests_section, mission, delegation, branch_embassy, (consulate/yes),
> consulate_general, consular_agency, consular_office, honorary_consul, 
> liaison_office,
> representative_office, subnational]
>
> we would save on keys and the main level (most mappers interested) would
> be in the amenity space and have just 3 different, simple tags with
> reasonable level of detail.
>
>
> or amenity=[embassy, consulate, minor_mission]
> embassy=[embassy/yes, nunciature, high_commission, interests_section,
> mission, delegation, branch_embassy]
> consulate=[consulate/yes, consulate_general, consular_agency,
> consular_office, honorary_consul]
> minor_mission =[liaison_office, representative_office, subnational]
>
> diplomatic=[trade_office, assistance_office, cultural_center,
> user_defined]
>
> (integrating your diplomatic:type)
>
>
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

Am Di., 30. Okt. 2018 um 18:48 Uhr schrieb Allan Mustard :

> Not really dropping.  More like reorganizing.  As someone who has spent
> hours puzzling over Maperitive's rendering rules, deciding how to build
> them so that particular categories of POIs will be rendered in specific
> ways, I am quite sensitive to the need for consistency and a finite number
> of possible permutations while also accommodating the need to cover every
> eventuality.  Hierarchies are designed for exactly that purpose.  After
> much back and forth at this point I am proposing a hierarchy that I believe
> meets all needs without being overly complex, and which will accommodate
> the novice mapper (diplomatic=embassy, period) and the advanced mapper
> (diplomatic=embassy, embassy=interests_section, etc.).
>
> diplomatic=* would become a top-level, primary tag.  It would have three
> categories: embassy, consulate, other.
>

to make this work, projects like osm carto would either have to add a
column for this key to their dbs or mappers would have to add something
like amenity=diplomatic on top of all tags (and likely it will lead to the
second way of doing it). It would make sense, if amenity=diplomatic was
sufficient information for a significant number of people, it doesn't make
sense if amenity=diplomatic does not convey the required information.


> If the consensus is that "other" sucks as an option I'm certainly open to
> other suggestions, but we need something for diplomatic missions headed by
> neither an ambassador/charge d'affaires (i.e., subject to the VCDR) nor a
> consul (i.e., subject to the VCCR).
>

diplomatic=minor_mission? If there's neither a consul nor an ambassador, it
must be somehow minor ;-)



> Then the real fun begins.  As I have read through the various comments and
> suggestions, it has occurred to me that the following hierarchy of tags
> would potentially fill the bill:
>
> The three values/categories (embassy, consulate, other) would have
> specific subcategories.  If you wanted to do a key search in overpass
> turbo, it would still be possible. The subcategories would be
>
> * embassy=[embassy/yes, nunciature, high_commission, interests_section,
> mission, delegation, branch_embassy]
>
> * consulate=[consulate/yes, consulate_general, consular_agency,
> consular_office, honorary_consul]
>
> * other=[liaison_office, representative_office, subnational]
>

if these are all exclusive, it could also be:

amenity=[embassy, consulate, minor_mission]
diplomatic=[(embassy/yes), nunciature, high_commission, interests_section,
mission, delegation, branch_embassy, (consulate/yes), consulate_general,
consular_agency, consular_office, honorary_consul, liaison_office,
representative_office, subnational]

we would save on keys and the main level (most mappers interested) would be
in the amenity space and have just 3 different, simple tags with reasonable
level of detail.


or amenity=[embassy, consulate, minor_mission]
embassy=[embassy/yes, nunciature, high_commission, interests_section,
mission, delegation, branch_embassy]
consulate=[consulate/yes, consulate_general, consular_agency,
consular_office, honorary_consul]
minor_mission =[liaison_office, representative_office, subnational]

diplomatic=[trade_office, assistance_office, cultural_center, user_defined]

(integrating your diplomatic:type)


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

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

[Allan Mustard]

Not really dropping.  More like reorganizing.  As someone who has spent
hours puzzling over Maperitive's rendering rules, deciding how to build
them so that particular categories of POIs will be rendered in specific
ways, I am quite sensitive to the need for consistency and a finite
number of possible permutations while also accommodating the need to
cover every eventuality.  Hierarchies are designed for exactly that
purpose.  After much back and forth at this point I am proposing a
hierarchy that I believe meets all needs without being overly complex,
and which will accommodate the novice mapper (diplomatic=embassy,
period) and the advanced mapper (diplomatic=embassy,
embassy=interests_section, etc.).  And by the way, it is radically
different from my original proposal.

diplomatic=* would become a top-level, primary tag.  It would have three
categories: embassy, consulate, other.  If the consensus is that "other"
sucks as an option I'm certainly open to other suggestions, but we need
something for diplomatic missions headed by neither an ambassador/charge
d'affaires (i.e., subject to the VCDR) nor a consul (i.e., subject to
the VCCR).

Then the real fun begins.  As I have read through the various comments
and suggestions, it has occurred to me that the following hierarchy of
tags would potentially fill the bill:

The three values/categories (embassy, consulate, other) would have
specific subcategories.  If you wanted to do a key search in overpass
turbo, it would still be possible. The subcategories would be

* embassy=[embassy/yes, nunciature, high_commission, interests_section,
mission, delegation, branch_embassy]

* consulate=[consulate/yes, consulate_general, consular_agency,
consular_office, honorary_consul]

* other=[liaison_office, representative_office, subnational]

(if I have missed any, please don't condemn me, just diplomatically
mention it, as it's late at night here). These subcategories would allow
overpass turbo searches as well as proper rendering by applications. 
They would also constitute a finite universe that covers all
contingencies (possibilities are indeed finite), making rendering and
searching much easier.

Now the super fun:  as I plowed through the comments, I realized we need
some functional categories, too, what in OSM are sometimes called
subtypes.  I am inspired by the way we specify types of motor fuel
available at a gas station:

* diplomatic:type=[trade_office, assistance_office, cultural_center,
user_defined]  If these are located away from the main chancery (which
happens a lot), they need to be mapped separately; if however such
offices are inside the main chancery (which also happens a lot) they
would not be mapped separately. 

We have also discussed having a tag like this, or something similar:

* diplomatic:services:[non-immigrant visas, immigrant visas, citizen
services]=[yes/no]

As to some of Johnparis' specific questions/objections:

*I find this sentence in one of your emails to be particularly
problematic on this subject:*
*
*
*/A trade mission (aka "trade commissioner", "commercial office",
"trade representative") can be part of any of the three categories;
it is not accredited separately/**.**
**
**If someone needs to be an expert on international law to determine
the tag, there's a problem with the tagging scheme.*

You don't need to be an expert.  You just need to be able to read.  If a
trade office is attached to an embassy, it is tagged as
diplomatic=embassy.  If it is attached to a consulate, it is tagged as
diplomatic=consulate.  If it is part of a liaison office or similar
"other" category, it is tagged diplomatic=other.  You don't have to be a
lawyer or international relations expert; you just have to read the sign
on the door or peruse the establishment's website to figure it out.

*delegation -- not mentioned**
**UN -- not mentioned -- probably should be same as permanent_mission**
**trade_delegation -- not mentioned**
**visa -- not mentioned (I believe these are for private companies
that handle visas on behalf of consulates -- where to categorize?)*

*dele**gation* is typically considered a type of embassy (U.S.
Delegation to the United Nations, for example).  It is headed by an
ambassador.  Refer back to the rule of thumb that if it has an
ambassador, it is an embassy.

*UN* is not a separate type of diplomatic establishment.  It is an
international organization.  UN headquarters should be tagged office=*
but its diplomatic missions abroad should be tagged as
diplomatic=other.  They are not headed by ambassadors (please see my
previous comments on this subject).  Same holds for OSCE, OECD, and so on.

*trade_delegation* is another name for
trade_office=trade_representative=commercial_office, and we should seek
some modicum of standardization to avoid overproliferation of tags. If I
were an American chauvinist, I would insist on commercial_office, since
that is what the U.S. 

Re: [Tagging] Area with restaurants, hotels, cinemas - is it landuse=commercial?

[Michael Patrick]

> If it’s 40 storeys of apartments above a 3 storey mall, use landuse=retail
for the whole mall area, and building=apartment for the residential towers.
The whole, larger mall building could probably be building=mall; it sounds
like there are several tall but narrow residential towers around or on top
of a bigger mall.

You're describing ( in the USA anyways) Mixed Use classification.
>From https://en.wikipedia.org/wiki/Mixed-use_development
*Mixed-use development is a type of urban development that blends
residential, commercial, cultural, institutional, or entertainment uses,
where those functions are physically and functionally integrated, and that
provides pedestrian connections. Mixed-use development can take the form of
a single building, a city block, or entire neighbourhoods. The term may
also be used more specifically to refer to a mixed-use real estate
development project—a building, complex of buildings, or district of a town
or city that is developed for mixed-use by a private developer, (quasi-)
governmental agency, or a combination thereof. *

In the USA, under the impetus of Growth Management legislation in most
states and metropolitan areas, the concept isn't only restricted to urban
areas.

> Commercial areas are less important but are still more likely to be
destinations of trips, compared to residential and industrial.

There is lots of trip data, but most trips are multiple pairs and or
multi-modal.
> I initially disliked the idea of only tagging retail landuse for mixed-use
> urban centers, but it makes sense based on the need to tag one feature on
> one area, and the limited options for rendering maps with overlapping
> landuse.

Back in 1994, after examining existing schemes, the APA came up with the
LBCS  as a minimal schema to make
sense of the semantics of LULC. The EU also has a similar LULC
harmonization under the INSPIRE framework
.

Michael Patrick
Data Ferret
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Another multipolygon question

[Kevin Kenny]

On Tue, Oct 30, 2018 at 7:54 AM Dave Swarthout 
wrote:

> Someone added the Arctic National Wildlife Refuge to OSM but did not add a
> bunch of inner areas that aren't part of the refuge. I have the inners in a
> shapefile that end up in a separate layer when I import them into JOSM. I
> would like to add those inners to the existing boundary of the refuge. How
> can I transfer those inners from the shape layer to my data layer?
>
> I've tried everything I can think of, including the special paste function
> inside the Relation Toolbox I learned about recently, but cannot get them
> to transfer *en masse*. I can copy and paste them one at a time but there
> are a few dozen tiny parcels. I also tried pasting them in place and then
> using JOSM's Search function to select "type:way untagged new" and that
> worked but it's clumsy.
> There must be a better way to do this.
>

If you have just the one multipolygon in the shapefile, or you have just
the inners in the shapefile, it's pretty easy.

Import the shapefile into JOSM. Yes, it comes in as a new layer.

Select the inner rings by whatever means.  One possibility is to delete the
outer ring (just don't save the shapefile again, or save it under a new
name before you start so that you can throw it away) and then 'Select All'
followed by 'Select->Unselect Nodes' (Shift+U). Copy the inner ways
(Ctrl+C).

Switch to the OSM layer and do Ctrl+Alt+V (Paste at Source Location).

You now have your newly pasted items selected. Bring up the relation editor
on your relation, and you'll see the selected items in the right-hand
column. Use the 'insert at the bottom' button in the middle bar to bring
them over. into the relation.

Now they're in the left-hand column, and still selected.  Type 'inner' in
the 'role' prompt at the bottom and hit the check mark. Now they're all
inner ways.

If you're afraid of losing the selection, add some tag like 'dave=1' to the
items before you copy-n-paste, and then the Search dialog can find them
easily. (Don't forget to delete the tag when you're done!)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Another multipolygon question

[Dave Swarthout]

Kevin,

Okay, I see understand the offset now and the reasons for doing it but wow,
such attention to detail is unusual in OSM mapping methinks. It was clever
indeed. I just began to use QGIS but I'm a complete noobie at it. My only
use of it so far has been to select and save into its own folder a single
shapefile (for a national Park or National Wildlife Refuge) from a monster
master file containing many individual shapefiles and even that took some
searching on Youtube before I could  pull it off. That is one powerful
program and learning how to use it isn't for the fainthearted. I love the
Adirondacks region and fear that at my age and physical remove (Alaska for
summers, Thailand winters) I'll never get a chance to hike there again. I'm
glad you are working to map that wonderful wilderness area.

Gosh, it seems I'll never run out of questions. Here's yet another.

Someone added the Arctic National Wildlife Refuge to OSM but did not add a
bunch of inner areas that aren't part of the refuge. I have the inners in a
shapefile that end up in a separate layer when I import them into JOSM. I
would like to add those inners to the existing boundary of the refuge. How
can I transfer those inners from the shape layer to my data layer?

I've tried everything I can think of, including the special paste function
inside the Relation Toolbox I learned about recently, but cannot get them
to transfer *en masse*. I can copy and paste them one at a time but there
are a few dozen tiny parcels. I also tried pasting them in place and then
using JOSM's Search function to select "type:way untagged new" and that
worked but it's clumsy.
There must be a better way to do this.

Thanks for your help, everyone.

On Mon, Oct 29, 2018 at 7:06 PM Kevin Kenny  wrote:

> On 10/29/18 2:48 AM, Dave Swarthout wrote:
> > But I'm still a bit confused about way:427547729. It's tagged as an
> > outer in the Wilcox WF multipolygon but it's located inside of an
> > enclosing way that's also an inner to the same relation. Does that
> > mean the inner/outer roles alternate as you add more and more "nested"
> > objects to the large multipolygon? For example,iIf there was a block
> > of private property inside way:427547729 would that be tagged as inner?
>
> You got it. That's why I chose that specific one as an example, to show
> how 'exclave within enclave' works. It's unusual, but it happens.
>
> > Just to touch on another topic because Kevin mentioned it. Sometimes
> > it's fairly obvious that certain boundaries were meant to follow a
> > riverbank or a coastline but at the present time don't. My first
> > impulse is to delete segments of the original boundary and replace
> > them with the more recent riverbank or coastline. That would probably
> > be considered wrong by some but seeing as we do not and can not
> > guarantee perfect accuracy with the placement of any boundary I don't
> > see it as an absolute no-no. Plus, many of these boundaries use
> > thousands of nodes that follow every little zig-zag to achieve legal
> > accuracy. IMO, OSM doesn't need that level of detail.
> >
> > Opinions?
>
> I think you're right about the level of detail, and in fact I simplify
> ways fairly often.
>
> Because partly of confusing advice here, in 'imports', in talk-us, and
> on the Wiki, when I did the reimport of the Adirondack protected areas,
> I did them as separate ways. In order to be able to simplify them, I
> used an 'erode' operation (a 'buffer' operation with negative size)
> where the size was slightly larger than the simplification tolerance to
> offset the ways before simplifying. At the time, I couldn't find such a
> beast in JOSM, so I used QGIS to do it.
>
> What happened to change my mind was further discussion here about
> administrative boundaries, and the way that the offset ways looked
> around the corridors that were cut out of some areas for existing roads
> and railroads. I've been sporadically changing the borders from offset
> ways to shared ways. You can see a partly-done example at
> https://www.openstreetmap.org/#map=16/43.8523/-74.2274 where the west
> side of Gooley Club Road is conflated and shared, while the east side is
> not. That's actually a 'not-too-bad' example since the Primitive Area
> corridor extends a hundred feet (~30 m) from the road centerline on
> either side. (Gotta fix the road designation, too - it's yet another
> TIGER Residential!. Grrr.) The corridor at
> https://www.openstreetmap.org/#map=16/44.0071/-73.9362 applies
> 'Primitive Area' protection to a three-rod right-of-way, and there was
> absolutely no way to get the ways simplified and aligned without
> conflating them (and in that case, why not make them a shared way?)
>
> I still think my approach was valid for the initial import, particularly
> since the boundaries in the source data were drawn so as to require
> manual conflation otherwise. I discussed this issue at the time in
> 'imports' and heard no complaints. In fact, one commenter 

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

[Johnparis]

The problem I see is that, as I understand it, Allan is proposing to drop
some existing diplomatic=* values, such as diplomatic=permanent_mission.
And the proposed substitute is to rely on the name=* tag.

Martin pointed out a problem where something not an embassy has a name like
an embassy. But also the proposal to "just search on the name" will fail
if, for example, the tagging is something like this:

office=diplomatic
diplomatic=other
name=مهمة تجارية من ليبيا

If you're looking for trade missions, I doubt very much that you'll find
that one. On the other hand, you will find it if the tag diplomatic=mission
is used (I'm not proposing that as a value, but see below).

On a similar note, I don't think the subtags proposed under "other" will
ever gain widespread use. "Other" means "end of the road" to most people.
Basically, anything you're thinking of under "other" that warrants its own
category should be elevated one level, and "diplomatic=other" should be
dropped. The trick is deciding on what categories are significant enough to
merit a separate tagging value. Currently you're at "embassy, consulate,"
but I'd challenge you to go further.

I find this sentence in one of your emails to be particularly problematic
on this subject:

*A trade mission (aka "trade commissioner", "commercial office", "trade
representative") can be part of any of the three categories; it is not
accredited separately*.

If someone needs to be an expert on international law to determine the tag,
there's a problem with the tagging scheme.

Looking at taginfo (thanks for the correct link, Martin), I see that there
are very, very few subtags currently in use for diplomatic=*
embassy
consulate
consulate_general -- folded into consulate under current proposal -- this
makes sense to me
honorary_consulate -- folded into consulate -- is that right? My experience
with honorary consuls is that they are more like private citizens promoting
trade
high_commission -- folded into embassy -- sensible
permanent_mission -- not mentioned -- should be folded into embassy?
delegation -- not mentioned
UN -- not mentioned -- probably should be same as permanent_mission
trade_delegation -- not mentioned
visa -- not mentioned (I believe these are for private companies that
handle visas on behalf of consulates -- where to categorize?)
non_diplomatic -- becomes "other" -- I think this should be dropped entirely

You also had a partial list of proposed tags for "other" ...
liaison_office
representative_office
subnational
trade_office
cultural_center
assistance_office

These are all candidates for values of diplomatic=* (I doubt most need
their own category, and thus should be dropped). In particular the
"subnational" tag is already implied by the existence of a hyphen in the
"sending_country" (US-VA for Virginia, for instance).

Finally, on the question of whether to make the main tag "office" or
"diplomatic" -- this reminds me of the discussion several years back for
the Internet's top-level domains (.com, .edu, .uk, etc...), which are now
free-for-all. As Martin pointed out, certain existing programs (like the
openstreetmap.org map) assume a small subset of top-level tags, and adding
to that small subset is not easy. So I would advocate for office=diplomatic
as the main tag rather than trying to create a new main tag.

John





On Tue, Oct 30, 2018 at 10:09 AM Warin <61sundow...@gmail.com> wrote:

> On 29/10/18 21:23, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
> On 29. Oct 2018, at 11:18, Martin Koppenhoefer 
> wrote:
>
> At the moment mappers can simply tag by using the name
>
>
>
> here’s an example for a misleading name tag:
> https://www.openstreetmap.org/node/332554285
>
>
> Just to make it clear.
>
> I am only using things already tagged amenity=embassy, but missing a
> diplomatic tag and then using the associated name value to determine what
> diplomatic value to add.
>
> Not simply every name tag in the data base... that could lead to some
> interesting results.
>
> There are some things miss-tagged as amenity=embassy .. one is a school (I
> have re-tagged that), I think 3 others are brothels... fixmes in place now.
> ___
> 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 29/10/18 21:23, Martin Koppenhoefer wrote:



sent from a phone

On 29. Oct 2018, at 11:18, Martin Koppenhoefer > wrote:



At the moment mappers can simply tag by using the name



here’s an example for a misleading name tag:
https://www.openstreetmap.org/node/332554285



Just to make it clear.

I am only using things already tagged amenity=embassy, but missing a 
diplomatic tag and then using the associated name value to determine 
what diplomatic value to add.


Not simply every name tag in the data base... that could lead to some 
interesting results.


There are some things miss-tagged as amenity=embassy .. one is a school 
(I have re-tagged that), I think 3 others are brothels... fixmes in 
place now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging