Re: [Tagging] Marking climbing proposal as "in use"

[Mike Thompson]

I am not opposed as I think it is a good starting point, but I have these
comments:

"Crags" are only small areas
My understanding from 15 years in this activity is that a "crag" is a small
area as explained here [1]. At least in the US, no one would refer to El
Cap [2] as a "crag" yet it is something that should be mapped if one is
mapping things related to climbing.

Climbing areas, including crags, are hierarchical in organization and
suitable for representation as a relation
For example, in Colorado, US, the Shelf Road[3] climbing area, consists of
a number of "sub" areas, including Sand Gulch[4], Sand Gulch also consists
of further sub areas, and these areas contain individual routes.

"climbing:bolted" should include "mixed"
Some routes have some bolts for protection, but also require placement of
gear (cams, pitons).

Need tag to indicate if pitons are allowed
(they damage the rock)

Need rating (difficulty) tag for aid climbing[5]


[1] https://en.wikipedia.org/wiki/Glossary_of_climbing_terms#crag
[2] https://en.wikipedia.org/wiki/El_Capitan
[3] https://www.mountainproject.com/v/shelf-road/105744267
[4] https://www.mountainproject.com/v/sand-gulch/105744971
[5] https://en.wikipedia.org/wiki/Aid_climbing#Grading

On Thu, Jan 28, 2016 at 8:36 AM, Richard  wrote:

> Hi,
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/Climbing
>
> was sitting around and evolving for 8 years. If there are no
> objections I would promote its status to "in use".
>
> Afaics it has never attracted significant controversy, does not
> trigger any technical difficulties, there is demand for it and
> is well used considering that it is a domain relevant only for
> a minor fraction of mappers.
>
> Richard
>
> ___
> 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] Discussion about Multivalued Keys

[Daniel Koć]

W dniu 28.01.2016 10:45, Martin Koppenhoefer napisał(a):

2016-01-27 16:45 GMT+01:00 Daniel Koć :


* shop types (as already mentioned on proposition page)
* amenity types (like fast_food + pub)
* long inscriptions on monuments/memorials (above 255 chars)


those all don't seem valid examples, a pub serving fast food is still
a pub, a shop fitting into several shop types is likely none of these


And probably a fast food serving beer is still a fast food. But you have 
to choose what is "main" feature before making such statement and it's 
not always clear.



shop types (but a different one), and circumventing the maximum value
length shouldn't be done by distributing the value over several keys
(if we wanted people to write essays in the tag values we could remove
the 256 byte restriction).


This is a real life tagging problem I had once and you seem to not 
propose any way to resolve it in a different way.


It has nothing to do with promoting long entries, it is just an issue to 
be solved somehow.


--
"Завтра, завтра всё кончится!" [Ф. Достоевский]

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

Re: [Tagging] Marking climbing proposal as "in use"

[Tom Pfeifer]

Richard wrote on 2016/01/28 16:36:

Hi,

http://wiki.openstreetmap.org/wiki/Proposed_features/Climbing

was sitting around and evolving for 8 years. If there are no
objections I would promote its status to "in use".


Well it is in use indeed, and the tag page has already further
developed than the proposal page above.
https://wiki.openstreetmap.org/wiki/Tag:sport%3Dclimbing
Taginfo=8449

The tag page says "in use" already, the proposal page could be
archived.


Afaics it has never attracted significant controversy, does not
trigger any technical difficulties, there is demand for it and
is well used considering that it is a domain relevant only for
a minor fraction of mappers.


A very important fraction, as they can survey from the summit! :-)

Mike Thompson wrote on 2016/01/28 17:49:
> Climbing areas, including crags, are hierarchical in organization and 
suitable for representation as a relation

Interesting idea, might become tricky to realise. Next question,
does it help? Would it just be a collection, like 'all museums in Paris',
which I can express as a query already?

> "climbing:bolted" should include "mixed"
> Some routes have some bolts for protection, but also require placement of 
gear (cams, pitons).

That should be no problem and is better than the "average bolt distance in 
meters"
documented on the tag page (only used a few dozen times, should be a separate 
key)

> Need tag to indicate if pitons are allowed (they damage the rock)

There was also "dry tooling" proposed 3 days ago on the climbing-tag talk page.

> Need rating (difficulty) tag for aid climbing[5]

Should not be difficult:
Climbing styles
  climbing:aided=[yes|no]
  climbing:grade:aided:[min|max|mean]=*
or so.

tom


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

Re: [Tagging] Marking climbing proposal as "in use"

[Mike Thompson]

On Thu, Jan 28, 2016 at 4:19 PM, Tom Pfeifer  wrote:

>
>> Mike Thompson wrote on 2016/01/28 17:49:
> > Climbing areas, including crags, are hierarchical in organization and
> suitable for representation as a relation
>
> Interesting idea, might become tricky to realise. Next question,
> does it help? Would it just be a collection, like 'all museums in Paris',
> which I can express as a query already?

This is not the same as "all museums in Paris" as there are no
administrative boundaries that typically define a climbing "area."  These
are just conventions that local climbers have developed over the years.  In
some cases they have been subsequently signed by the land manager (e.g. in
the U.S. the BLM or National Park Service), but their "boundary" is not
delimited. There might be a single sign that says "Trail to xyz Climbing
Area"

>
>
> > Need rating (difficulty) tag for aid climbing[5]
>
> Should not be difficult:
> Climbing styles
>   climbing:aided=[yes|no]
>   climbing:grade:aided:[min|max|mean]=*
> or so.

What one person may aid, another may free (I am using "free climbing" in
the US sense  [1]).  A typical route rating would be "5.9/A3 or 5.13" (in
the US) meaning if you would free the entire route you would encounter 5.13
climbing, but it could be divided into some 5.9 free climbing and some A3
aid climbing.

Mike

[1] https://en.wikipedia.org/wiki/Free_climbing

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

Re: [Tagging] Discussion about Multivalued Keys

[Martin Koppenhoefer]

2016-01-28 6:59 GMT+01:00 Warin <61sundow...@gmail.com>:

> Use the layer key?
>
> barrier=fence
> fence=barbed_wire
> layer=0  ... not required
>
> barrier=fence
> fence=wire_electric
> voltage=300
> layer=1
>
> Would need two ways ... messy. Not good.
>


we could use a relation to avoid overlapping ways, something for linear
features, and maybe also something for nodes (e.g. different traffic signs
on the same pole). Using multivalues
There is already a proposal for these:
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Node
The line relation might be expressed as a route (e.g. route=barrier), but
it would be better to allow for non-continuous ways as well (often bigger
barriers tend to have bifurcations and deadends, e.g. the chinese wall).

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

Re: [Tagging] Discussion about Multivalued Keys

[Warin]

On 28/01/2016 4:52 PM, Marc Gemis wrote:

Other keys that might need multiple values:

* barrier / fence_type : barbed wire with an electrified wire on top.
A wall with barbed wire on top ,...  We need some kind of vertical
order here.

Use the layer key?

barrier=fence
fence=barbed_wire
layer=0  ... not required

barrier=fence
fence=wire_electric
voltage=300
layer=1

Would need two ways ... messy. Not good.


* information: board / map. for those information spots that show a
map of the area + a description of the history, the nature and / or
the access rules.

On Wed, Jan 27, 2016 at 4:09 PM, Colin Smale  wrote:

Dear all,

I have created a proposal page as a channel for constructive debate about
the way forward. I hope you will all take a look and participate!

Although this subject is a bit more than just a proposal for a new tag, I
have used the same template. I will try and flesh it out a bit more in the
coming days, but everyone is of course welcome to add their stuff.

http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys



--colin




___
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] Discussion about Multivalued Keys

[Martin Koppenhoefer]

2016-01-27 16:45 GMT+01:00 Daniel Koć :

> * shop types (as already mentioned on proposition page)
> * amenity types (like fast_food + pub)
> * long inscriptions on monuments/memorials (above 255 chars)
>


those all don't seem valid examples, a pub serving fast food is still a
pub, a shop fitting into several shop types is likely none of these shop
types (but a different one), and circumventing the maximum value length
shouldn't be done by distributing the value over several keys (if we wanted
people to write essays in the tag values we could remove the 256 byte
restriction).

But there are keys which might require multiple values, like the mentioned
cuisine and destination. Not sure for ref, typically these would be
different kind of refs, i.e. would be better in this case to specify the
kind of ref (e.g. ref:vatin).

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

Re: [Tagging] Feature Proposal - RFC - Government offices

[Martin Koppenhoefer]

2016-01-28 12:43 GMT+01:00 Colin Smale :

> Sounds like there are formally two distinct bodies in Paris which share
> buildings and staff.



calling them distinct is a bit of a stretch, given that location and people
are the same. There one "thing" that does cover both admin levels. They
might act in different roles and according to different rules, but they are
the same "thing". That's exactly what I had in mind when speaking about
entities covering more than one admin level.

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

Re: [Tagging] Discussion about Multivalued Keys

[moltonel 3x Combo]

On 27/01/2016, Colin Smale  wrote:
> On 2016-01-27 22:54, moltonel 3x Combo wrote:
>> Concerning foo_1 vs foo[1] vs foo:1, I this the last one can be safely
>> thrown to the idea bin (despite being used by seamarks) because ':'
>> clashes with namespacing, which is firmly established. foo[1] looks
>> better than foo_1 to my programer eyes, but is has no technical
>> advantage (?) and I suspect that most people will find foo_1 more
>> pleasing, it's also one less character to type, less annoying to parse
>> with a regexp, and much more established in taginfo.
>
> Would you feel any different about your foo:1 example if it were written
> foo%1, avoiding any clash with namespacing?

I don't really care wether it's _1, %1 or [1], except that the first
one is already popular. But

> By the way, I am trying to maintain the distinction between the "suffix
> notation" where the index value is actually the final part of the key
> segment, and the "hierarchical/seamark" notation where the index value
> is a separate segment of the full key string.

As far as I'm aware, the "suffix notation" has always meant "suffix
within a namespace", not "suffix at the very end of the key". We
already have a significant number of "*name_1:*" keys in the db, for
example.

> Maybe we should look at some technical use cases, like "in a navigation
> map creator, find all the categories for a POI" or "find the per-lane
> destination (and destination:ref and turn-lane stuff) information so I
> can construct a simulated road sign". Some will be done with a
> programming language, others may naturally tend towards SQL.
>
>> Concerning using '.' as a separator instead of ':', I don; t see what
>> it brings us, beside familiarity to users of some programing languages
>> (but change language and sudenly ':' becomes more familiar).
>
> Sometimes using a familiar character (such as the ":" here) with new
> semantics can lead to confusion. There comes a point when it is better
> to make a clean break so there is no confusion. Whether it is a colon or
> a dot or some other character is "detail" really.

Yes, but in the "lane[1].destination=Paris" example, you use '.' for
something (namespacing) that we've always happily used ':' before. I
don't see a need for the change, my best guess was "it looks more
familiar to users of some programming languages" but IMHO it's not
worth the confusion it'll bring to most people.

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

Re: [Tagging] Feature Proposal - RFC - Government offices

[Matthijs Melissen]

On 27 January 2016 at 15:03, Frederik Ramm  wrote:
> 1. In many western civilizations you have a division of state powers in
> an executive, a legislature, and a judiciary. I believe that you'd
> normally only call the executive "government", although colloquially
> people will say "the government has passed a law" or "the government has
> put him in prison" too.

Isn't the division of powers theory referred to as 'three branches of
government'? That seems to indicate that government can encompass the
legislative power as well.

Also, note that on local level, the branches are much more mingled,
and usually share a single building (the city council usually meets in
the building where the mayor/aldermen work).

> For a government=* tag to succeed, it would have to be clearly
> delineated for what kinds of things it is to be used. The proposed
> definition is already murky; for example, a job centre or even a museum
> cashier could be "fully paid for by the government and completely
> controlled by them". This is not any better defined than
> amenity=public_building.

Good point. Do you, or anybody else, have a better definition? I think
I'd prefer the job center to be included, but the museum to be
excluded.

> 2. At the same time, governments all over the world are vastly
> different; in some places, for example, the water works will be closely
> guarded government institutions, and in others, private enterprises in
> competition to each other. Same with railways and many other utilities
> which, at least in socialist countries, tend to be practically
> inseparable from government (except that it will be bloody difficult to
> assign an admin_level to them). I think that it is very likely that
> you'll end up with a vastly varying use of this tag across the world,
> with many values limited in use to a single country plus a few uses
> sprinkled across the world because nobody understood that a certain type
> of office really only exists in three Philippine provinces.

True, but I don't think that's really a problem. If the reality is
different in across countries, we can expect the tagging to differ as
well. I think the wiki page should provide some international
guidelines, but in the end each national community can decide how to
implement them (similarly to how each country decides what counts as a
trunk road).

> 3. Personally I feel that in addition to the above, there's a major
> difference between places where the government provides a service to the
> citizen - where you go to do something or have something done - and
> other places where the government essentially revolves in its own sauce
> and you're not even let in to watch. The former is an useful "this is
> where you go if you need to " information, the latter is essentially
> just for fancy lettering on the map because you won't usually go there
> for anything. Much like the difference between a Domino's pizza place
> and the Domino's central franchise building. I think that it might make
> sense to find different tags for the government "outlets" or "serivce
> points" as opposed to government office buildings.

Good point as well. However, note that this differs a lot between
countries as well. For example, in some countries, if you have a tax
question, you can just walk in to the tax office, where'll you be
redirected to the tax inspector that will actually handle your tax
forms. In other countries, you can only reach the tax office by phone
or mail. There are also many forms in between places where you can
just walk in, and places that are closely guarded. For example,
ministry buildings are generally relatively closed off, but sometimes
you might need to go there to get certain documents. For instance, in
Luxembourg you can register your diplomas in person at the higher
education ministry. An other example, you would not usually go to the
city's traffic department are usually, but you might need to go there
if you need signs to close of a parking space.

-- Matthijs

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

Re: [Tagging] Feature Proposal - RFC - Government offices

[Colin Smale]

I didn't have any "concerns", I was looking for clarity about what was
meant by an "institution" given that a "city hall" was cited as an
example... 

Sounds like there are formally two distinct bodies in Paris which share
buildings and staff. The fact that a given council meeting is either one
thing or the other is a big clue: 

"Although Paris has a double role as a _commune_ and as a _département_,
it has a unique method for governing both; the Council of Paris, with
the Mayor of Paris as its president, meets either as a municipal council
(_conseil municipal_) or as a departmental council (_conseil général_)
depending on the issue to be debated." 

>From the website of the Mairie: 

"LES CONSEILLERS DE PARIS siègent à la fois au Conseil d'arrondissement
dont ils sont élus et au Conseil de Paris où ils ont une double fonction
: ils sont à la fois conseillers municipaux et conseillers
départementaux." 

//colin 

On 2016-01-28 12:16, althio wrote:

> Colin,
> 
> Please see https://en.wikipedia.org/wiki/Council_of_Paris
> and tell me if it answers your questions and if I understood your concerns.
> 
> - althio
> 
> On 28 January 2016 at 12:10, Colin Smale  wrote: 
> 
>> What do you mean with "institution"? Is that a single building housing
>> multiple organisations, or is it a single organisation fulfilling multiple
>> constitutional roles? A "City Hall" sounds like a building.
>> 
>> Organisations sharing a building probably happens quite a lot, but I would
>> expect that governments are wary of combining multiple distinct admin levels
>> into a single organisation where the admin levels actually exist.
>> 
>> --colin
>> 
>> On 2016-01-28 11:58, althio wrote:
>> 
>> On 28 January 2016 at 11:47, Matthijs Melissen 
>> wrote:
>> 
>> On 28 January 2016 at 11:43, Martin Koppenhoefer 
>> wrote:
>> 
>> Only problem: if an institution
>> serves several levels we will either loose information (e.g. by using only
>> the highest level) or deal with multiple values (but that's no different
>> from "government:level=state;local".
>> 
>> Do you have an example of an institution serving multiple admin levels?
>> 
>> Maybe Paris city hall would fit the description, serving admin_level=6-8:
>> http://www.openstreetmap.org/relation/71525
>> http://www.openstreetmap.org/relation/1641193
>> http://www.openstreetmap.org/relation/7444
>> and http://www.openstreetmap.org/relation/284089
>> 
>> ___
>> 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] Discussion about Multivalued Keys

[markus schnalke]

Hoi,

I'd like to share some thoughts about the ``How to implement MV in
OSM'' question, as opened in:
http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys

I'd prefer to first have explicit agreement that we actually need
MV ... but as the implementation discussion is already rolling ...

Initially, I wanted to add a section to the talk page of the wiki
page but my text now appears to be better suited for an email. Please
feel free to integrate any part of my considerations into the wiki
page.



I see two general ways to solve the problem of MV in OSM:

1) Allow multiple identical keys per object (as is was before API
0.6, I learned). This means tag names of one object need *not* be
unique. When we talk about tag names being unique, we should
distinguish between being unique in the data storage and being
unique at the surface (GUI). It seems ... well, what does it seem?
Are we more concerned about the technical storage level or at the
user experience? Which of them are we discussing?


2) Make multiple identical keys by some *technical* measurement
unique. This is the currently assumed way to go, at least as such
it appears to me.

I (now) think that it is important to keep the value domain free
from logic and thus have it reserved for literal data. This means,
MV need to be implemented in the key domain.

Currently, we mostly discuss with concrete examples. The assumption
is, that the user would have to deal with these suffixes. Maybe he
doesn't have to. It might be possible to abstract the user's view
from the internal storage. Then the actual encoding becomes
irrelevant from the user's perspective. Multiple identical keys
could be presented to him (even grouped) ... and they'd be
translated (e.g.  by appending arbitrary suffixes (e.g. hashes of
the value)) at the interface to the data storage layer. (I focus
on unordered MVs here.)

As a user, I'd never want to have to deal with this MV problem at
all, which means no encoding should be required by me, neither in
the value *nor* in the key domain. If there are two refs, then I'd
want to tag: ref=foo + ref=bar. The internal storage should not be
the user's problem.

Of course, it's not that easy, because raw data is dealt with much
too often. Nonetheless we should kept in mind, that a separation
of the user's view from the data storage can solve colliding wishes.


Concerning the choice, of how to add such a suffix:

We should realize what we try to do here: We're violating the
first normal form for relational databases, by encoding two
separate bits of information in one field (the key's name and some
unique suffix). We already came to the opinion, that encoding
multiple values in one field in the value domain is bad ... but it
is equally bad in the key domain.

And it is even worse if the separator is not (technically)
reserved for that specific purpose. If we would use the underscore
(_) to separate the key's name from the unique suffix, then the
technical separation of name and suffix would be pretty fragile,
because names already contain underscores. The split would be
rather guessing, based on the suffix to be a number.

Hence, if we do encode two separate values in one field, then we
better try hard to make the separator reserved. This not only
spares us escaping, but also allows us to search for exact key
names, because the search engine can then be enabled to know which
is the name to compare and which is the suffix to ignore.

The underscore approach fails in this respect equally as the colon
approach. Of the currently discussed approaches, only the subscript
(bracket) syntax satisfies this need. (Assuming that there are no
brackets in key names, currently.) However, it's closing bracket
is technically superfluous and only motivated by the thinking that
humans have to see these suffixes.


What we need in my opinion is one single character, that must
never be part of any key name and never be part of any suffix.
Using this separator, we encode two separate bits of information
in one field (the key field) ... and thus have effectively three
columns in a two-column table.

At the surface (GUI) we should rather hide the technical suffix
stuff.


meillo


P.S.
Ordered MVs are not considered here. It is not clear if we need
to consider them.

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

Re: [Tagging] wetland=bog, why only "receive their water and nutrients from rainfall"?

[John Sturdy]

There's an explanatory notice in Cambridge University Botanical
Gardens, indicating that fens are fed with water from limestone /
chalk springs, which is relatively alkaline, whereas bogs, being fed
by rainwater, are relatively acidic.  The different pH means that
different ranges of plants will grow there.


On Mon, Jan 25, 2016 at 10:59 AM, David Marchal  wrote:
>
>
> 
>> Date: Sun, 24 Jan 2016 15:59:24 +
>> From: ajt1...@gmail.com
>> To: tagging@openstreetmap.org; tagging@openstreetmap.org
>> Subject: Re: [Tagging] wetland=bog, why only "receive their water and 
>> nutrients from rainfall"?
>>
>> What does "fen" means to you?
>>
>> I've a fairly good idea what I think it means, and I'd never or almost never 
>> tag it as a natural feature (though it may have a name, and the natural 
>> features within it may have names).
>
> In my current understanding, the main difference is that fens at least partly 
> receive water from groundwater, like springs, flow and streams, while bogs 
> are isolated from groundwater and only get water from rain.
>
> Hope I'm not saying you something stupid here, but, if that can help you…
> ___
> 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 - Government offices

[Martin Koppenhoefer]

2016-01-27 21:38 GMT+01:00 Warin <61sundow...@gmail.com>:

> government:level=federal,state,local ?
> OR
>
> This could also be operator tag = federal_government, etc ... that would
> be more consistent?
>
> OR
> use admin_level tag from the boundaries tag
>
> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#admin_level
>


yes, as we already have them, the admin_levels seem great to add this
information this way (it will provide the detail relative to the rest of
the map data, i.e. administrative entities). Only problem: if an
institution serves several levels we will either loose information (e.g. by
using only the highest level) or deal with multiple values (but that's no
different from "government:level=state;local". We might even consider using
relations for this, so the area that is served can become member of the
object and the role could tell what the connection is.

I agree with Frederik about the separation of powers and the usage of the
term government (it seems in some countries this distinction is less
prominent and "government" serves as a collector for all kind of official
public powers). For reference, a similar discussion was held here:
https://lists.openstreetmap.org/pipermail/tagging/2015-March/022449.html
an particular from here on:
https://lists.openstreetmap.org/pipermail/tagging/2015-March/022509.html


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

Re: [Tagging] Feature Proposal - RFC - Government offices

[althio]

On 28 January 2016 at 11:47, Matthijs Melissen  wrote:
> On 28 January 2016 at 11:43, Martin Koppenhoefer  
> wrote:
>> Only problem: if an institution
>> serves several levels we will either loose information (e.g. by using only
>> the highest level) or deal with multiple values (but that's no different
>> from "government:level=state;local".
>
> Do you have an example of an institution serving multiple admin levels?

Maybe Paris city hall would fit the description, serving admin_level=6-8:
http://www.openstreetmap.org/relation/71525
http://www.openstreetmap.org/relation/1641193
http://www.openstreetmap.org/relation/7444
and http://www.openstreetmap.org/relation/284089

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

Re: [Tagging] Discussion about Multivalued Keys

[Martin Koppenhoefer]

2016-01-27 18:00 GMT+01:00 moltonel 3x Combo :

> You barely broach the subject of how MV and namespaces combine. For
> example if an object has multiple refs with sources, it should be
> clear wether an MV tag corresponds to "multiple sources for all the
> refs" or to "source for the 2nd ref". In suffix syntax, this could be
> distriinguished by "ref_1=x ref_2=y source_1:ref=a source_2:ref=b" vs
> "ref_1=x ref_2=y source:ref_1=a source:ref_2=b", even though this is
> becoming hairy.
>



I believe we should restructure the way we use metadata aside with data in
the particular tags source and maybe note and fixme (but not description).
We are trying to convince people to add source tags on the changesets, but
putting them on individual objects still has strong advocates, so we will
likely have to live with it. As an idea, the source information could
become a subtag of another tag, i.e. rather than being attached to an
object it would be attached to a tag (or to the position). This could also
become more refined with several, optional formalized source tags, e.g. for
the source date, a source link, a source license(?), etc.

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

Re: [Tagging] Discussion about Multivalued Keys

[Warin]

On 28/01/2016 8:51 PM, Martin Koppenhoefer wrote:


2016-01-27 18:00 GMT+01:00 moltonel 3x Combo >:


You barely broach the subject of how MV and namespaces combine. For
example if an object has multiple refs with sources, it should be
clear wether an MV tag corresponds to "multiple sources for all the
refs" or to "source for the 2nd ref". In suffix syntax, this could be
distriinguished by "ref_1=x ref_2=y source_1:ref=a source_2:ref=b" vs
"ref_1=x ref_2=y source:ref_1=a source:ref_2=b", even though this is
becoming hairy.



Errr I would rather see

ref_1=x
source:ref_1=y

Keep the value the same from the first key to the delimited referrer = 
makes it easier for all to recognise and sort.



I believe we should restructure the way we use metadata aside with 
data in the particular tags source and maybe note and fixme (but not 
description). We are trying to convince people to add source tags on 
the changesets, but putting them on individual objects still has 
strong advocates, so we will likely have to live with it.


Some of my change sets have more than one source, I document to 
discriminate the sources  as well as I can. But it is a good deal clear 
to me if I put it on the way/node/relationship.
As an idea, the source information could become a subtag of another 
tag, i.e. rather than being attached to an object it would be attached 
to a tag (or to the position). This could also become more refined 
with several, optional formalized source tags, e.g. for the source 
date, a source link, a source license(?), etc.


name:source= ? Rather than source:name=... humm That would make people 
think about the source being part of some characteristic of the object.


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

[Colin Smale]

What do you mean with "institution"? Is that a single building housing
multiple organisations, or is it a single organisation fulfilling
multiple constitutional roles? A "City Hall" sounds like a building.

Organisations sharing a building probably happens quite a lot, but I
would expect that governments are wary of combining multiple distinct
admin levels into a single organisation where the admin levels actually
exist. 

--colin 

On 2016-01-28 11:58, althio wrote:

> On 28 January 2016 at 11:47, Matthijs Melissen  
> wrote: On 28 January 2016 at 11:43, Martin Koppenhoefer 
>  wrote: Only problem: if an institution
> serves several levels we will either loose information (e.g. by using only
> the highest level) or deal with multiple values (but that's no different
> from "government:level=state;local". 
> Do you have an example of an institution serving multiple admin levels?

Maybe Paris city hall would fit the description, serving
admin_level=6-8:
http://www.openstreetmap.org/relation/71525
http://www.openstreetmap.org/relation/1641193
http://www.openstreetmap.org/relation/7444
and http://www.openstreetmap.org/relation/284089

___
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 - Government offices

[althio]

Colin,

Please see https://en.wikipedia.org/wiki/Council_of_Paris
and tell me if it answers your questions and if I understood your concerns.

- althio

On 28 January 2016 at 12:10, Colin Smale  wrote:
> What do you mean with "institution"? Is that a single building housing
> multiple organisations, or is it a single organisation fulfilling multiple
> constitutional roles? A "City Hall" sounds like a building.
>
>
>
> Organisations sharing a building probably happens quite a lot, but I would
> expect that governments are wary of combining multiple distinct admin levels
> into a single organisation where the admin levels actually exist.
>
> --colin
>
> On 2016-01-28 11:58, althio wrote:
>
> On 28 January 2016 at 11:47, Matthijs Melissen 
> wrote:
>
> On 28 January 2016 at 11:43, Martin Koppenhoefer 
> wrote:
>
> Only problem: if an institution
> serves several levels we will either loose information (e.g. by using only
> the highest level) or deal with multiple values (but that's no different
> from "government:level=state;local".
>
>
> Do you have an example of an institution serving multiple admin levels?
>
>
> Maybe Paris city hall would fit the description, serving admin_level=6-8:
> http://www.openstreetmap.org/relation/71525
> http://www.openstreetmap.org/relation/1641193
> http://www.openstreetmap.org/relation/7444
> and http://www.openstreetmap.org/relation/284089
>
> ___
> 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 - Government offices

[Matthijs Melissen]

On 28 January 2016 at 11:43, Martin Koppenhoefer  wrote:
> Only problem: if an institution
> serves several levels we will either loose information (e.g. by using only
> the highest level) or deal with multiple values (but that's no different
> from "government:level=state;local".

Do you have an example of an institution serving multiple admin levels?

-- Matthijs

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