Re: [Tagging] Using multipolygons to map bays in Alaska

[Christoph Hormann]

On Friday 16 November 2018, Dave Swarthout wrote:
>
> To answer Christoph's question about Chickaloon Bay and the node for
> the same bay, I simply forgot to delete the redundant node after I
> finished. Interestingly, the label for the new multipolygon fell only
> slightly to the east of the node so its placement was fairly
> accurate. However, in order to see the name on that node, one must
> zoom in so far that you have no idea whatsoever of the physical
> extent of the actual object. I know, that's a rendering issue. Still,
> the reason many of us enjoy mapping is so we can see the results of
> our labors somehow, preferably on a map, so it's a powerful incentive
> to do things in such a way that results in visualization. There is an
> enduring tension in the OSM world that we're always seeking to
> balance and this discussion is largely about where that balance lies.

Yes, as already said i understand that and this is why i do not 
primarily blame you or other mappers for using non-verifiable drawings 
to map bays and straits but Daniel for incentivizing that for 
ultimately selfish reasons.

As a data user i am relatively relaxed on this because it is not a big 
problem to reduce all these polygon drawings to a node before i use the 
data.  But i would not want to map or do data maintainance in an area 
with such drawings.  I see this as a problem of pollution control.  Not 
to litter the environment, not to pollute the air just because it is 
convenient.

> Also, sorry, I cannot see how representing a strait the size and
> importance of the Shelikof Strait (every Alaskan knows about this
> famous water passage) with a single way could work. A way is totally
> inadequate for such a task. Maybe that trick would work for a narrow
> strait that resembles a fjord but not for one as large as this one.

Yes, i completely understand how this seems this way but i also know 
that this is due to you not realizing how fairly easily you can 
computationally assess the shape and the size of the street from a 
single properly placed node.  I will keep this case in mind for the 
future as a good example to illustrate that.

Note the current node:

https://www.openstreetmap.org/node/561722

is of course not suitably placed.  Correct position would be around 
here:

https://www.openstreetmap.org/?mlat=57.9877&mlon=-154.0407#map=9/57.9877/-154.0407

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Neighborhood Gateway Signs?

[Martin Koppenhoefer]

Am Fr., 16. Nov. 2018 um 02:48 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Here in Indonesia it is very common for neighbors to build sign over
> the main entrance to their neighborhood, with the name of the
> neighborhood on top and some other info on the two columns supporting
> the sign.
> ...
> These can't be "city limit" / "town limit" signs, because they are
> just for a neighborhood and they are near the center rather than at
> the border.




they don't even look like "traffic_sign"s, I'd suggest a different tag for
them. Maybe "information"?

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

Re: [Tagging] Using multipolygons to map bays in Alaska

[Dave Swarthout]

That node too was left behind by mistake. I just now deleted it.

The problem with using a way is that I can't see it. And I bet most current
map products can't render it either. That someone with special cartographic
skills can render it is good to know but it doesn't really help my
situation. If those nodes can do the job you claim they for them, then
someone needs to make it work that way on OSM, or OSMAnd.

I don't know why Daniel made the choice to map that huge bay with
multipolygons but calling it pollution isn't going to help matters.

On Fri, Nov 16, 2018 at 6:26 PM Christoph Hormann  wrote:

> On Friday 16 November 2018, Dave Swarthout wrote:
> >
> > To answer Christoph's question about Chickaloon Bay and the node for
> > the same bay, I simply forgot to delete the redundant node after I
> > finished. Interestingly, the label for the new multipolygon fell only
> > slightly to the east of the node so its placement was fairly
> > accurate. However, in order to see the name on that node, one must
> > zoom in so far that you have no idea whatsoever of the physical
> > extent of the actual object. I know, that's a rendering issue. Still,
> > the reason many of us enjoy mapping is so we can see the results of
> > our labors somehow, preferably on a map, so it's a powerful incentive
> > to do things in such a way that results in visualization. There is an
> > enduring tension in the OSM world that we're always seeking to
> > balance and this discussion is largely about where that balance lies.
>
> Yes, as already said i understand that and this is why i do not
> primarily blame you or other mappers for using non-verifiable drawings
> to map bays and straits but Daniel for incentivizing that for
> ultimately selfish reasons.
>
> As a data user i am relatively relaxed on this because it is not a big
> problem to reduce all these polygon drawings to a node before i use the
> data.  But i would not want to map or do data maintainance in an area
> with such drawings.  I see this as a problem of pollution control.  Not
> to litter the environment, not to pollute the air just because it is
> convenient.
>
> > Also, sorry, I cannot see how representing a strait the size and
> > importance of the Shelikof Strait (every Alaskan knows about this
> > famous water passage) with a single way could work. A way is totally
> > inadequate for such a task. Maybe that trick would work for a narrow
> > strait that resembles a fjord but not for one as large as this one.
>
> Yes, i completely understand how this seems this way but i also know
> that this is due to you not realizing how fairly easily you can
> computationally assess the shape and the size of the street from a
> single properly placed node.  I will keep this case in mind for the
> future as a good example to illustrate that.
>
> Note the current node:
>
> https://www.openstreetmap.org/node/561722
>
> is of course not suitably placed.  Correct position would be around
> here:
>
>
> https://www.openstreetmap.org/?mlat=57.9877&mlon=-154.0407#map=9/57.9877/-154.0407
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Using multipolygons to map bays in Alaska

[Christoph Hormann]

On Thursday 15 November 2018, Kevin Kenny wrote:
> >
> > Data of subjective value for a specific application (like low
> > quality label rendering) - yes, obviously.  Meaningful additional
> > information about the verifiable geography - no, i don't think so.
>
> By 'low quality', I presume you mean 'of a quality that can be
> achieved algorithmically rather than by manual label placement by a
> skilled cartographer?' Otherwise, what's your approach to higher
> quality?

No, what i mean here is that labeling a bay based on the non-verifiable 
polygon drawing of the mapper alone without taking into account the 
geographic context (like the coastline, potentially also other features 
like neighboring straits and bays with their labels) is inevitably low 
quality.  The additional non-verifiable data is only useful for such 
low quality efforts, it is of no use for higher quality approaches.

> [...]
> It is only once the spatial extent is determined that a renderer can
> do a good job of label placement.

No, this is an insight that you get at one point when working on rules 
for high quality labels that for optimal label placement of features 
like a bay or a strait which largely have no verifiably defined two 
dimensional extent knowledge of an arbitrary declared extent is not 
helpful.

Maybe that is a special perspective i have as an engineer working as a 
designer - as an engineer you learn that degrees of freedom that are 
not contrained by design requirements are not a nuisance but a highly 
desirable chance to actually optimize efficiency and quality.  Taking 
this over to cartographic design the geometrically undefined nature of 
a bay or strait is what gives you much of the freedom to optimize the 
design and placement of a label and scuttling that with the illusion of 
a defined extent is sad.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Using multipolygons to map bays in Alaska

[Daniel Koć]

W dniu 16.11.2018 o 12:24, Christoph Hormann pisze:

> Yes, as already said i understand that and this is why i do not
> primarily blame you or other mappers for using non-verifiable drawings 
> to map bays and straits but Daniel for incentivizing that for 
> ultimately selfish reasons.


Using strong words, blaming, judging etc. is not helping to solve
anything, it's rather making it harder. But I understand that's your
opinion.

Rendering perfectly documented and used features sounds like a good
thing for the entire project, no matter how do you call my reasons and
who do you choose to blame.


> Correct position would be aroundhere:
>
> https://www.openstreetmap.org/?mlat=57.9877&mlon=-154.0407#map=9/57.9877/-154.0407


It would be much more useful if you tell now how to verify position of
this node?

And why do you tell "around" if this is sure method, not just your
random choice? I remember that your claim is verification is that other
user would do the same. It certainly does not work this way in this case
- some other user put it in a different place already. So there are at
least 2 different positions - hard to say that it confirms or proves
anything.

I am fully aware that drawing area is not fully verifiable. But you
claim that drawing a node is better in that particular respect. How can
you prove it?


-- 
"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] Using multipolygons to map bays in Alaska

[Christoph Hormann]

On Friday 16 November 2018, Daniel Koc4� wrote:
>
> It would be much more useful if you tell now how to verify position
> of this node?

Quoting from:

https://wiki.openstreetmap.org/wiki/Tag:natural%3Dstrait

"when mapping as a node this node should usually best be placed 
approximately in the middle between the coasts of the strait at the 
narrowest point"

And just for ease of everyone the matching quote from

https://wiki.openstreetmap.org/wiki/Tag:natural%3Dbay

"When you map a bay as a node the node should be placed approximately at 
the middle of the bay with equal distance to the coast enclosing the 
bay on all sides."

In the previous discussion i linked to i formulated it a bit more 
precisely:

"If you want to formulate a formal mathematical rule for where the node 
for a bay is best placed: Place it so the variance of the distance of 
the node to the bay's shores is minimized.  Most existing nodes comply 
with this rule remarkably well."

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Using multipolygons to map bays in Alaska

[Daniel Koć]

W dniu 16.11.2018 o 14:31, Christoph Hormann pisze:

> Quoting from: 


Thanks, that was really helpful answer.

The problem is that I have asked you how to draw verifiable node, not
"what is a good practice for drawing a node using verifiable
operations". Let's look closer:


> in the middle between the coasts of the strait at the 
> narrowest point"

The hidden prerequisite here is to know which part of the coast belongs
to the strait and which is not. But when you know it, it's also easy to
define equally (also not fully) verifiable area:

"take the coast that belongs to the strait and link the ends with lines
without crossing them"


> approximately at 
> the middle of the bay with equal distance to the coast enclosing the 
> bay on all sides."


When you claim that you don't know which part of the coastline belongs
to the bay, how do you measure a middle of that?


> "If you want to formulate a formal mathematical rule for where the node 
> for a bay is best placed: Place it so the variance of the distance of 
> the node to the bay's shores is minimized.  Most existing nodes comply 
> with this rule remarkably well."


Again - distance "to the bay's shores", so first you know which parts of
the shore belong to the bay (you don't take the whole continent for
sure) and then do some strict operation with it (but chosen by some
convention).

So we claim that we don't know the bay borders, but we derive a node
from them. When somebody will claim that the coastline around the bay is
different (longer, shorter, has different starting and ending nodes
etc.), the node would be placed somewhere else. And while you both can
agree on the algorithm, the input is different, so most probably the
output will be different too. There can be only verification of applying
the same procedure, but not the object (or a node) itself.

And it can't be. The only fully verifiable water area is the one fully
surrounded by the land (excluding problems with intermittent waters).
Then drawing the coastline is fully accurate, because you might choose
different ways to draw a node for it and only one way to draw the area.
Any water area that is even partly open (to the sea, river, lake etc.)
is not fully (100%) verifiable. But the node is also not verifiable,
because you need to start with some assumptions about where it starts or
ends for a given object to make some formal operations on it.

My preference is to show the borders explicitly, so the user will choose
what to do with it (measure the area, show the borders, put a node this
or the other way...) and has a mostly realistic picture of the object.
Making node is hiding the borders, size and shape as an implicit choice
on behalf of all the users.

I don't say that nodes should be never used for bays or straits. I just
claim that they are less usable than areas, because they loose more
data, while being also never fully verifiable. Both are just conventions
to describe some place on the water, because there are no clear borders
on the water.

That is also why the coastline is never fully verifiable, but I would be
against solving it by using a node instead of a conventional straight
line - visible for example on La Plata estuary up to z7:

https://www.openstreetmap.org/query?lat=-36.29153&lon=-56.77843#map=7/-35.782/-55.684


-- 
"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] Using multipolygons to map bays in Alaska

[Graeme Fitzpatrick]

Following with interest (& I've got to say, that with my admittedly limited
knowledge, that I agree with Dave, Kevin & Daniel's interpretation of how
to do it).

On Sat, 17 Nov 2018 at 09:48, Daniel Koć  wrote:

>
> That is also why the coastline is never fully verifiable, but I would be
> against solving it by using a node instead of a conventional straight
> line - visible for example on La Plata estuary up to z7:
>
>
> https://www.openstreetmap.org/query?lat=-36.29153&lon=-56.77843#map=7/-35.782/-55.684


With regard to the River Plate, when you look at how it's been mapped as a
multipolygon https://www.openstreetmap.org/relation/3474227, why is the
name shown where it is? I would have thought that with everything being
"equal", the name would have been pretty well on a straight line between La
Plata & Montevideo, & on a N - S line between the final A in Nueva Helveci
*a* & the left hand angle in the international maritime border?

& I'll also add that if I'd done the amount of work that Daniel or Rober
had, then someone came along, said "I don't agree with the way you've done
that", & deleted it all, then I'd be extremely cheesed off! :-(

Thanks

Graeme


>
>
>
> --
> "Excuse me, I have some growing up to do" [P. Gabriel]
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Using multipolygons to map bays in Alaska

[Paul Allen]

On Sat, Nov 17, 2018 at 12:28 AM Graeme Fitzpatrick 
wrote:

>
> & I'll also add that if I'd done the amount of work that Daniel or Rober
> had, then someone came along, said "I don't agree with the way you've done
> that", & deleted it all, then I'd be extremely cheesed off! :-(
>

I'd find that bad enough even had he been right in his interpretation.
Given how he has explained
it so far, I don't see that he is (but that could simply be me being
incapable of following it).  His
interpretation seems to me to be, let's say, highly idiosyncratic: you're
not allowed to draw a border
out at sea because that's not verifiable, you have to imagine that same
border then do complicated
calculations based upon the imaginary border you haven't drawn in order to
place a node there; that
way it's much more verifiable because nobody can see where your imaginary
border was or if you did
the calculations correctly or if you just shoved the node there for
label-painting or even at random.
And if you based your border on out-of-copyright navigation charts showing
the sheltering extent of
the bay, or based it on depth readings, you're still wrong because reasons.

Given all that, I would find his behaviour unconscionable in a newbie, let
alone (if another poster here
was correct about this) a DWG member because it seems tantamount to
vandalism.  The fact that this
was done by a DWG member (if he is one) makes me reconsider how much effort
I'm willing to put
into mapping.  Maybe he, or somebody like him, will take issue with
something I've done and without
discussing it with me simply delete it.  Not ask me why I did it that way,
not suggest a better way of doing
it, not point me at a relevant wiki page backing his/her reasoning, just
delete it.  Then I'd go on
wasting my time merrily doing it the wrong way and he'd carry on merrily
deleting what I've done,
which is not very productive.

Perhaps he hasn't explained his reasoning simply enough that fools like me
can understand it.
Perhaps if he manages to do that I'll back him up on his decision and help
him go around deleting
the work of others.  Until and unless that happens, I'm feeling vicariously
cheesed off for Daniel.

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

Re: [Tagging] Using multipolygons to map bays in Alaska

[Christoph Hormann]

On Saturday 17 November 2018, Daniel Koc4� wrote:
>
> The problem is that I have asked you how to draw verifiable node,
> [...] 

No, you have not, you have asked:

> It would be much more useful if you tell now how to verify position
> of this node?

And i told you exactly that.

We all know you think bays and straits should best be mapped with 
polygons and that it is a positive thing to steer mappers to doing that 
(which by the way is against the goals of OSM-Carto even if your 
opinion on this has merit).  You can try to justify that all you want - 
this does not change anything about the argument i gave against it - 
that the polygon drawing almost never adds any verifiable information 
on the geographic reality compared to a node or a linear way 
representation.

I know i will not change your opinion on this - countless non-successful 
discussions with you on much clearer and simpler matters have shown me 
that.  I can just hope most mappers will emancipate themselves from 
this and not invest their time and energy in mapping and maintining 
polygon mazes over coastal waters.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Using multipolygons to map bays in Alaska

[Daniel Koć]

W dniu 17.11.2018 o 02:00, Christoph Hormann pisze:
> On Saturday 17 November 2018, Daniel Koc4� wrote:
>> The problem is that I have asked you how to draw verifiable node,
>> [...] 
> No, you have not, you have asked:
>
>> It would be much more useful if you tell now how to verify position
>> of this node?
> And i told you exactly that.


I have told you exactly how to verify the shape of a strait/bay area
just by using even simpler operation (connecting the dots). So the area
is verifiable now, just because the operation is also fully verifiable -
isn't it?

Everything starts with assuming we know the borders of this area, which
is the source of all verifiability problems - not the operations.


> (which by the way is against the goals of OSM-Carto even if your 
> opinion on this has merit).  


I don't see any support for your opinion about it, there's nothing about
rendering polygons being bad (or good) in the goals you wrote.


> You can try to justify that all you want - 
> this does not change anything about the argument i gave against it - 
> that the polygon drawing almost never adds any verifiable information 
> on the geographic reality compared to a node or a linear way 
> representation.


You did not answer basic question, which helps to show how verifiable is
a node in the middle of some area: how do you measure a precise middle
of the completely unknown shape?

(If you don't have some other, hidden assumptions, which would be a
problem in itself.)


> I can just hope most mappers will emancipate themselves from 
> this and not invest their time and energy in mapping and maintining 
> polygon mazes over coastal waters.

When I edit any big city I find a lot of way and polygon mazes (a lot of
crossing lines). Maintaining them is a real problem I face from time to
time, yet nobody has proposed to remove them and use nodes instead.

Water areas will never be that bad in this respect, they are much simpler.


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



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

[Tagging] Feature Proposal - Voting - (office=diplomatic)

[Allan Mustard]

Pursuant to a request from another mapper to wait another week after 10
November before calling for a vote, I postponed the start of voting on
the office=diplomatic proposal to today.  Voting is now open.  Please
see
https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic
for the final version of the proposal, which underwent much modification
from the original--please be sure to acquaint yourself with the proposal
and to review the discussion page.  If you have questions to which you
cannot find answers on the discussion page (which contains the vast bulk
of e-mail discussion) please feel free to e-mail me directly.

I thank the many contributors of ideas, suggestions, and just plain
great intellectual discussion of this proposal as it evolved from a
simple "amenity=consulate" fix to a more comprehensive solution of how
to deal with all manner of diplomatic missions.  It was not only
valuable for me to get all the perspectives you offered (and to tap your
experience as mappers), it was just plain fun, too! 

Best regards to all, and please do not forget to vote!

Allan Mustard
apm-wa


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

Re: [Tagging] Using multipolygons to map bays in Alaska

[Kevin Kenny]

On Fri, Nov 16, 2018 at 8:01 PM Christoph Hormann  wrote:

> We all know you think bays and straits should best be mapped with
> polygons and that it is a positive thing to steer mappers to doing that
> (which by the way is against the goals of OSM-Carto even if your
> opinion on this has merit).  You can try to justify that all you want -
> this does not change anything about the argument i gave against it -
> that the polygon drawing almost never adds any verifiable information
> on the geographic reality compared to a node or a linear way
> representation.
>
> I know i will not change your opinion on this - countless non-successful
> discussions with you on much clearer and simpler matters have shown me
> that.  I can just hope most mappers will emancipate themselves from
> this and not invest their time and energy in mapping and maintining
> polygon mazes over coastal waters.
>

I think that I need to reduce the cases to something more concrete in order
to follow your argument that nodes are perfectly adequate to convey the
extent of bays, straits, estuaries and similar features well enough to map
them  - particularly on maps that have a constrained region of interest.

I'm fairly good at both mapping and rendering, and quite good indeed with
the mathematics and programming - but somehow I'm still not following how
to implement your suggestions. I am willing to be convinced, but so far you
have failed to convince me.

Let's consider a map that I actually would like someday to produce: a
large-scale map of the waterfront community of Inwood, New York.
https://www.openstreetmap.org/relation/174930 I'll want to have it on a
sheet of A4 or US Letter paper. The extents of the map will therefore
likely be west into the water, perhaps about as far as the jetty at the
airport; east nearly to the railroad station in Cedarhurst, south to
about the station in Far Rockaway, and north perhaps to the bridge in
Meadowmere Park.

By far the most significant label that must be placed on the map, given the
waterfront nature of the community, is Jamaica Bay. Only a small portion of
the main bay would appear within that box, but much of the west edge of
such a map would be the water of the bay. Jamaica Bay can be seen in its
entirety by zooming back to level 12 or 13 and panning the map to the west
- it is the large oval area from Inwood out to the Atlantic Ocean.

If the bay were an area feature, I would be able to place a label on the
area feature that is created by intersecting its extent with the region of
interest. But, because of indefinite boundaries, the use of an area feature
is denied to me.

Assume that I am willing to be flexible about the deduced extent of the bay
where it is indefinite. I do not care, for instance, whether its mouth is
placed at the narrowest part of the entrance, near the Marine Parkway
Bridge, or at the traditional start at the imaginary line that connects the
tip of the jetty that protrudes from Breezy Point to the tip of the pier at
Coney Island to its north.  I similarly don't necessarily demand absolute
precision about the boundary between Jamaica Bay and the back bays such as
the Head of Bay, Norton Basin, Motts Basin, Motts Creek, Hook Creek or
Thurston Basin - any reasonable answer is fine.

So - problem #1:  What point, line or area features do I need to place in
the OSM data base to determine that the water in question is part of
Jamaica Bay so that I can label it on that map? Given those features, what
is the computational pathway that can inform a renderer that such a label
needs to be placed?

I am not assuming that OSM-Carto, Mapnik, or indeed any other existing
rendering chain contains a complete implementation of all the logic needed.
Instead, I am seeking help to develop a detailed specification. If this,
and the questions that I plan to follow up with, are answerable in the data
model that you envision, then this sort of thing will have to be
programmed. I'm willing to try my hand at such an implementation and do any
reasonable amount of analysis and programming. I still lack a clear vision
of how to proceed - although having a clear description from you of the
objects that are required in the database may help be a start at that.

Share the insight that you claim to have that I lack. Convert me to your
way of thinking.  If you are in possession of such deep understanding, it
will surely not be difficult to demonstrate by a single example how you
solve the problem.

I anticipate answers that deflect the question. Because of that, I state:

If I cannot be given an answer to such a concrete problem, I will not
accept that the reason is that I am too stupid or unskilled to understand
your superior wisdom. Nor will I accept a bald assertion that I am asking
the wrong question. Producing a conventional map on a sheet of paper is a
reasonable thing to want to do even in our digital age: as I stated before,
a sheet of paper and a magnetic compass never have dead batteries, and
wa

Re: [Tagging] Feature Proposal - Voting - (office=diplomatic)

[Graeme Fitzpatrick]

On Sat, 17 Nov 2018 at 12:46, Allan Mustard  wrote:

>
> Best regards to all, and please do not forget to vote!
>

Done!

One possible (?) typo I noticed though, that may change meanings?

Under target=*

"or target =BE;EU:NATO

for
a mission accredited simultaneously to Belgium, the European Union, and the
North Atlantic Treaty Organization."

Should EU:NATO be a colon or a semi-colon?

Thanks

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

Re: [Tagging] Feature Proposal - Voting - (office=diplomatic)

[Allan Mustard]

Semicolon!  Sorry, my eyes are going bad!  Will fix.  Thanks, Graeme!

apm

On 11/17/2018 8:51 AM, Graeme Fitzpatrick wrote:
>
>
> On Sat, 17 Nov 2018 at 12:46, Allan Mustard  > wrote:
>
>
> Best regards to all, and please do not forget to vote!
>
>
> Done!
>
> One possible (?) typo I noticed though, that may change meanings?
>
> Under target=*
>
> "or target =BE;EU:NATO
> 
>  for
> a mission accredited simultaneously to Belgium, the European Union,
> and the North Atlantic Treaty Organization." 
>
> Should EU:NATO be a colon or a semi-colon?
>
> Thanks
>
> Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging