Feature Proposal - RFC - (consulate)

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Warin
On 13/11/18 01:07, Allan Mustard wrote:
Not contrived at all in these days of tight budgets. I see no reason the inverse would not work. I’ll add it.

I think there are too many things in the proposal. Keep it simple. Yes the 'extras' might sound nice but they add complexity and each one is a point that can lead to someone objecting to that specific thing and leading to enough no votes that it fails.

Make the proposal on office=diplomatic only and it should pass.

Then, if you want pursue the other items individually. Personally I don't like lumping things together and then separating them at a lower level when it was separated before - I refer to the diplomatic=* tag that is in use now compared to the proposed diplomatic=embassy(includes high commission etc)/consulate (includes consulate general)/and some other thing that I don't recall.



Sent from my iPhone

On Nov 12, 2018, at 12:31 PM, Colin Smale <[hidden email]> wrote:

On 2018-11-11 21:51, Graeme Fitzpatrick wrote:

Just for the sake of asking a theoretical question that I know would probably never appear in real life :-)
 
Would / could you also use the multi-letter codes as you show eg NATO, WTO, SEATO?
 
& a mixture of them, so the British Ambassador to Belgium, who is also the delegate / representative to NATO (if there is such a thing?), would be
country=GB
target=BE;NATO
 
It's possible I guess to have the inverse of that as well, where the embassy of e.g. France also houses the ambassador of e.g. Monaco, both being accredited to the same receiving nation? (contrived example)
 
If a mission "represents" multiple countries, and the services offered are different, how could that be tagged? Something like the full Embassy of A also housing consular services for B.
 
Possibly two OSM objects, one for the embassy of A and a separate node for the services on behalf of B?
 
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Colin Smale

On 2018-11-12 22:00, Warin wrote:

On 13/11/18 01:07, Allan Mustard wrote:
Not contrived at all in these days of tight budgets. I see no reason the inverse would not work. I'll add it.

I think there are too many things in the proposal. Keep it simple. Yes the 'extras' might sound nice but they add complexity and each one is a point that can lead to someone objecting to that specific thing and leading to enough no votes that it fails.

At moments like this I like to invoke one of my heroes: Albert Einstein. One famous saying attributed to him is: As simple as possible, but no simpler.

If you simplify complex realities too much, you lose valuable detail. If it's complex, it's complex. If you want to leave out a level of detail, such as being able to distinguish between the different types of services provided on behalf of multiple "tenant" countries in a diplomatic mission, then so be it, but let's discuss whether it is desirable to leave that out, and whether the resultant ambiguity is acceptable. Data modelling means constructing an approximation to reality, and is all about what details to keep in and what to leave out. Once it is left out, it cannot be reconstructed from the rest of the data. (If it can, your data model is not properly normalised.)

If OSM is being limited to being suboptimal because of politics and the inability to reach consensus, I would rather the system was fixed instead of condemning the whole business to eternal mediocrity.



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Allan Mustard

Warin, may I please remind you that in your message of 31 October you were the mapper who expressed great concern about loss of data?

On 11/13/2018 2:37 AM, Colin Smale wrote:

On 2018-11-12 22:00, Warin wrote:

On 13/11/18 01:07, Allan Mustard wrote:
Not contrived at all in these days of tight budgets. I see no reason the inverse would not work. I'll add it.

I think there are too many things in the proposal. Keep it simple. Yes the 'extras' might sound nice but they add complexity and each one is a point that can lead to someone objecting to that specific thing and leading to enough no votes that it fails.

At moments like this I like to invoke one of my heroes: Albert Einstein. One famous saying attributed to him is: As simple as possible, but no simpler.

If you simplify complex realities too much, you lose valuable detail. If it's complex, it's complex. If you want to leave out a level of detail, such as being able to distinguish between the different types of services provided on behalf of multiple "tenant" countries in a diplomatic mission, then so be it, but let's discuss whether it is desirable to leave that out, and whether the resultant ambiguity is acceptable. Data modelling means constructing an approximation to reality, and is all about what details to keep in and what to leave out. Once it is left out, it cannot be reconstructed from the rest of the data. (If it can, your data model is not properly normalised.)

If OSM is being limited to being suboptimal because of politics and the inability to reach consensus, I would rather the system was fixed instead of condemning the whole business to eternal mediocrity.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Warin
What I am suggesting;

Stage 1 - Vote on office=diplomatic as a replacement for amenity=embassy

Once that is past
Stage 2 - vote on diplomatic=embassy/consulate/?
with embassy=embassy/high_commission/?
consulate=consulate/consulate_general/?
?=?/?

Stage 3 .. if you have further things.

That way each vote is on one issue only not the lot bundled together.


Once that is past On 13/11/18 12:22, Allan Mustard wrote:

Warin, may I please remind you that in your message of 31 October you were the mapper who expressed great concern about loss of data?

On 11/13/2018 2:37 AM, Colin Smale wrote:

On 2018-11-12 22:00, Warin wrote:

On 13/11/18 01:07, Allan Mustard wrote:
Not contrived at all in these days of tight budgets. I see no reason the inverse would not work. I'll add it.

I think there are too many things in the proposal. Keep it simple. Yes the 'extras' might sound nice but they add complexity and each one is a point that can lead to someone objecting to that specific thing and leading to enough no votes that it fails.

At moments like this I like to invoke one of my heroes: Albert Einstein. One famous saying attributed to him is: As simple as possible, but no simpler.

If you simplify complex realities too much, you lose valuable detail. If it's complex, it's complex. If you want to leave out a level of detail, such as being able to distinguish between the different types of services provided on behalf of multiple "tenant" countries in a diplomatic mission, then so be it, but let's discuss whether it is desirable to leave that out, and whether the resultant ambiguity is acceptable. Data modelling means constructing an approximation to reality, and is all about what details to keep in and what to leave out. Once it is left out, it cannot be reconstructed from the rest of the data. (If it can, your data model is not properly normalised.)

If OSM is being limited to being suboptimal because of politics and the inability to reach consensus, I would rather the system was fixed instead of condemning the whole business to eternal mediocrity.



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Paul Allen
On Tue, Nov 13, 2018 at 2:37 AM Warin <[hidden email]> wrote:

That way each vote is on one issue only not the lot bundled together.

And then some people will vote against the initial proposal because it does not adequately
address known issues and is therefore incomplete.  They would fear that as soon as it is
approved people will start using it and resort to ad-hockery to fill in the gaps, resulting in a
mish-mash of inconsistent tagging before the next step is approved.  Remember that this
proposal went forward because people want it and they want it now.  They WILL fill any
gaps with ad-hoc tagging as soon as it is approved.

I'd prefer a fully-formed proposal which addresses all conceivable future complications.  As this
one has.  I agree that a complex proposal might contain some good stuff and some bad stuff,
but this one has been very well-thought out by an expert in the field and then subject to all the
nit-picking this list can throw at it.

I'd vote for it because it is a thing of craftsmanship and beauty.  Well, maybe not for that
reason exactly, but because I cannot conceive of anything better or see any serious flaws
in it.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Sergio Manzi
In reply to this post by Colin Smale
Colin,

I subscribe to every single word of your post... bravo!

Regards,

Sergio


On 2018-11-12 22:37, Colin Smale wrote:
> At moments like this I like to invoke one of my heroes: Albert Einstein. One famous saying attributed to him is: As simple as possible, but no simpler.
>
> If you simplify complex realities too much, you lose valuable detail. If it's complex, it's complex. If you want to leave out a level of detail, such as being able to distinguish between the different types of services provided on behalf of multiple "tenant" countries in a diplomatic mission, then so be it, but let's discuss whether it is desirable to leave that out, and whether the resultant ambiguity is acceptable. Data modelling means constructing an approximation to reality, and is all about what details to keep in and what to leave out. Once it is left out, it cannot be reconstructed from the rest of the data. (If it can, your data model is not properly normalised.)
>
> If OSM is being limited to being suboptimal because of politics and the inability to reach consensus, I would rather the system was fixed instead of condemning the whole business to eternal mediocrity.
>


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Sergio Manzi
In reply to this post by Paul Allen

Me too. I let my "namespacing" modification proposal die: this is not the time and the place.

BTW, can you quickly explain, to a newbie like me, who has voting rights and what the voting process will be? Can you point me to any documents about that?

Regards,

Sergio


On 2018-11-13 12:54, Paul Allen wrote:
...

I'd vote for it because it is a thing of craftsmanship and beauty.  Well, maybe not for that
reason exactly, but because I cannot conceive of anything better or see any serious flaws
in it.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Paul Allen


On Tue, Nov 13, 2018 at 2:13 PM Sergio Manzi <[hidden email]> wrote:

BTW, can you quickly explain, to a newbie like me, who has voting rights and what the voting process will be? Can you point me to any documents about that?


Voting is by editing the voting section of the proposal.  Anyone who has registered to be able to
edit the wiki can vote.

author of the proposal can set up a vote and can be used to figure out how to vote.  You edit
the wiki.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Sergio Manzi

Thanks!

... but I don't see a voting section in https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic

Is this because voting is not open yet?

Sergio


On 2018-11-13 15:26, Paul Allen wrote:


On Tue, Nov 13, 2018 at 2:13 PM Sergio Manzi <[hidden email]> wrote:

BTW, can you quickly explain, to a newbie like me, who has voting rights and what the voting process will be? Can you point me to any documents about that?


Voting is by editing the voting section of the proposal.  Anyone who has registered to be able to
edit the wiki can vote.

author of the proposal can set up a vote and can be used to figure out how to vote.  You edit
the wiki.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Paul Allen


On Tue, Nov 13, 2018 at 2:42 PM Sergio Manzi <[hidden email]> wrote:

... but I don't see a voting section in https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic

Is this because voting is not open yet?


Correct.  Once things have settled down enough on the list (I think we're already there) then
it will be opened for voting and that fact will be announced here.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Allan Mustard
In reply to this post by Sergio Manzi

Voting is not yet open.  Warin asked that the comment period be extended for another week, so I am acceding to his request. 

apm-wa

On 11/13/2018 7:41 PM, Sergio Manzi wrote:

Thanks!

... but I don't see a voting section in https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic

Is this because voting is not open yet?

Sergio


On 2018-11-13 15:26, Paul Allen wrote:


On Tue, Nov 13, 2018 at 2:13 PM Sergio Manzi <[hidden email]> wrote:

BTW, can you quickly explain, to a newbie like me, who has voting rights and what the voting process will be? Can you point me to any documents about that?


Voting is by editing the voting section of the proposal.В  Anyone who has registered to be able to
edit the wiki can vote.

author of the proposal can set up a vote and can be used to figure out how to vote.В  You edit
the wiki.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
123