Re: [Tagging] Wilderness huts

[Dave Swarthout]

Nico said, "As a mountaineer I was very intrigued by the hut discussion and
wanted
to share some of my knowledge on this area. I will however definitely
exceed the initial question in this message, since I'm more interested
in the differentiation between the tags."

Actually, the reason I started this discussion was to provide more
differentiation between the various hut types by making their definitions
clearer. Some of the information Niko is curious about can already be
provided by existing tags:

fee=yes/no
access=*
opening_hours=May-Oct ; Nov-Apr off
ele=1300
operator=*
owner=*
description=*
etc.

It's difficult to come up with a scheme that handles all the possibilities
especially if you consider the reality that most tag information will never
show up on a standard map. Someone just said in another thread I'm
following that if we are indiscriminate in adding tags we will soon reach a
point where for each feature we add, something else must get dropped. If
you talk about how to render all these details, it gets trickier still.

To get back to my original idea — if we can consolidate a few of these
huts, and better define what we have left, maybe it will be easier to map
them without reading through 3 pages of instructions as Janko says.

Obviously, there is interest in resolving this issue but I don't know which
direction to take at the moment.

Cheers,
Dave


On Thu, Apr 3, 2014 at 5:45 AM, Janko Mihelić  wrote:

> It's great to have new people enthusiastic about tagging.
>
> A good side of already existing tags (alpine_hut, shelter..) is that a
> mapper not very experianced in mountaineering can tag them easily without
> reading 3 pages of text. Also, non-specialized renderers don't have to
> think too much about them. They just put 2 kinds of icons and that's great.
>
> I don't think experienced mountaneers and specialized renderers should
> think much about those tags. They should treat alpine_huts, shelters,
> wildernes_huts, and hotels as the same thing. What they should look at are
> the specialized tags, and render according to them.
>
> Of course, if there are no specialized tags, there's not much they can do
> except render it as a question mark.
>
> So in my opinion, we should start with defining specialized tags, and stop
> trying to find boundaries for general terms.
> My apologies in advance if I break convention or code, but I just
> recently started mapping and even more recently joined the mailing list.
> As a mountaineer I was very intrigued by the hut discussion and wanted
> to share some of my knowledge on this area. I will however definitely
> exceed the initial question in this message, since I'm more interested
> in the differentiation between the tags.
>
> Of my experience in the Alps, larger huts are operated in season and can
> most often be accessed off-season as well, although this might require
> you to get a key somewhere in a nearby village. Often times only a
> smaller section of the hut is available off-season. Smaller unmanned
> huts (like Ren? Maroufi mentioned) can be considered emergency shelters,
> which rarely require a key. All huts vary in size and level of comfort.
>
> As a user of these huts key features I'd like to know about are:
> - What does it cost? (say the typical fee for an adult)
> - Do members of an Alpine society (DE: 'mitglieder') get a rebate?
> - Who/what operates the hut? (e.g. a certain person, a certain society)
> - Are you allowed to bring and cook your own food?
> - Period(s) of the hut being manned (can be multiple)
> - Contact information (phone, website, address, via common tags)
> - Capacity? (in number of persons both sleeping and visiting)
> - Facilities (e.g. running water, toilet, mattresses, blankets,
> electricity, lights)
> - Cooking/heating facilities and available fuel (often times a stash of
> wood is available)
> - Hut book available (for writing your name whilst on trip, for
> increased change of retrieval when something bad happens.
> - Deposit box for money available (or will you have to pay in town)
> - Last changes made to the hut (thereby determining the state of the
> hut) (via common tags)
> - Elevation (also via common tags)
> - Way of supply (helicopter, cableway, carriers) (this helps determine
> the likely cost of food and drinks) (a mapped helicopter landing site
> and a mapped cableway can help determine this, reducing the need for a
> tag).
>
> Now looking at available tagging schemes, I do recognize quit some of
> these parameters, but not all. In my opinion the tourism:x_hut and
> shelter_type:x should be combined (or at least be clearly separated).
>
> Depending on the tagging options, I believe a hut can be defined as
> being all the way from a basic shelter to a small hotel, therefore
> requiring a solid set of examples (from various countries) of hut
> types.
> Personally I'd prefer a more generic set of tags rather than having
> various definitions that implicitly define location (alpine_hut), use
> (em

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Janko Mihelić]

I think our own wikibase could be used to give a more structured semantic
meaning of tags, and combinations of tags.

For example, we want to define what a McDonalds restaurant is in our
database. Is it a node with name=McDonalds? Well, a parking lot could be
named the same. Is it a way with amenity=fastfood + name=McDonalds? Well,
in China they are called differently. Is it a relation, node or way with
franchise:wikidata=Q38076? What combination of tags is enough to be sure
that something is a McDonalds restaurant? We have to define that somewhere.

Well, this wikibase would be a database of all these combinations that can
be considered to have a specific meaning. Then those items could be
connected with Wikidata or other databases. Also, dataminers would have a
reliable place with defined queries for their needs.

But this is a bit offtopic.

Janko


2014-04-03 1:37 GMT+02:00 Jo :

> I'm afraid I don't fully understand the reasoning behind OSM having its
> own wikidata DB. What extra (different) data would we store in it, which
> couldn't go in Wikidata? I understand it in the case of Commons to store
> metadata like diaphragma and lenses used when taking those pictures.
> Oh, maybe we can store source and other metadata in it?.. But we're
> already storing our data in a DB, aren't we?
>
> Polyglot
>
>
> 2014-04-02 23:34 GMT+02:00 Janko Mihelić :
>
>> 2014-04-02 16:56 GMT+02:00 Andy Mabbett :
>>
>>
>>> There is also the case of sets;  for example, four carvings which form
>>> a single artwork, but which are mapped as separate entities.
>>>
>>
>> You could put the four carvings into a relation, and put the wikidata tag
>> there (along with the name=* and tourism=artwork). Or you could create four
>> wikidata items, and give them the attribute "part of" and connect with the
>> first item. Then reference those four items in OSM.
>>
>>
>> 2014-04-02 19:13 GMT+02:00 Andy Mabbett :
>>
>>
>>> One might also reasonably expect to find multiple instances of things
>>> like material:wikidata=Q23757 (that's limestone).
>>>
>>
>> I wasn't talking about xxx:wikidata=* tags. There can be lots of those.
>> All sculptures by one artist should have the same artist:wikidata=* tag.
>> All streets named after Nikola Tesla should 
>> havename:etymology:wikidata=Q9036. But there should be only one element with
>> wikidata=Q384, or any other number.
>>
>> P.S. I'm not sure we should reference materials from Wikidata. That's
>> going a bit too far. Tagging material=limestone should be enough. If we
>> want to go that far with connecting OSM tags with Wikidata, there are
>> better ways. I have thought about this, and with common tags like
>> material=* we could make our own Wikibase installation, and connect tag
>> combinations from OSM with Wikidata items.
>>
>> Janko
>>
>> ___
>> 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] simple_brunnel : one node bridge like xing highway over waterway

[Janko Mihelić]

Also -1 for the proposal.

Rationale in the Wiki says this would save us database space, we would have
2 ways and 1 node less per bridge. Also, that maintaining one node is
easier than maintaining 3 ways. Lastly, problem of pretending you have
drawn a little bridge precise, when you didn't.

All of these are valid points, but I think they don't overweight the
problems this would give us. We would break one of the most basic rules we
have, and we don't have much rules. We don't know what that could hurt. One
example are renderers who should learn how to render bridges with one
point. Second are mappers who like clear rules. And if we don't have those
core rules, future may bring us problems.

Maybe the biggest problem with this proposal is the feeling I got as soon
as I understood you wanted to map bridges as nodes. It felt wrong, and I
think a lot of mappers will feel the same way.

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Jo]

I'm afraid I don't fully understand the reasoning behind OSM having its own
wikidata DB. What extra (different) data would we store in it, which
couldn't go in Wikidata? I understand it in the case of Commons to store
metadata like diaphragma and lenses used when taking those pictures.
Oh, maybe we can store source and other metadata in it?.. But we're already
storing our data in a DB, aren't we?

Polyglot


2014-04-02 23:34 GMT+02:00 Janko Mihelić :

> 2014-04-02 16:56 GMT+02:00 Andy Mabbett :
>
>
>> There is also the case of sets;  for example, four carvings which form
>> a single artwork, but which are mapped as separate entities.
>>
>
> You could put the four carvings into a relation, and put the wikidata tag
> there (along with the name=* and tourism=artwork). Or you could create four
> wikidata items, and give them the attribute "part of" and connect with the
> first item. Then reference those four items in OSM.
>
>
> 2014-04-02 19:13 GMT+02:00 Andy Mabbett :
>
>
>> One might also reasonably expect to find multiple instances of things
>> like material:wikidata=Q23757 (that's limestone).
>>
>
> I wasn't talking about xxx:wikidata=* tags. There can be lots of those.
> All sculptures by one artist should have the same artist:wikidata=* tag.
> All streets named after Nikola Tesla should 
> havename:etymology:wikidata=Q9036. But there should be only one element with
> wikidata=Q384, or any other number.
>
> P.S. I'm not sure we should reference materials from Wikidata. That's
> going a bit too far. Tagging material=limestone should be enough. If we
> want to go that far with connecting OSM tags with Wikidata, there are
> better ways. I have thought about this, and with common tags like
> material=* we could make our own Wikibase installation, and connect tag
> combinations from OSM with Wikidata items.
>
> Janko
>
> ___
> 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] Ticket for JOSM to read contact metadata closed

[Andy Mabbett]

On 2 April 2014 18:37, Tobias Knerr  wrote:
> On 02.04.2014 19:25, Andy Mabbett wrote:

> The response probably refers to the fact
> that, unfortunately, very few business websites offer contact data in a
> machine-readable format.

Perhaps, though a number do.

But why would the machine-readable data need to be on their own
websites? We have such data, for example, in infoboxes on Wikipedia
articles.

> However, all hope is not lost: This functionality would be ideal for a
> JOSM plugin. And it's not unheard of that popular plugins later make it
> into JOSM itself.

So where do I request one of those?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Ticket for JOSM to read contact metadata closed

[Andy Mabbett]

On 2 April 2014 21:45, Dan S  wrote:

> I know how those microformats work but I don't feel that they're very
> common, so I don't have any particular problem with the reason given.
> Do you feel to the contrary, that they are "used much"? Do many
> business/organisation websites actually add these things?

There are many millions of them; but, as noted above, I specifically
referred to "an hCard microformat or some other contact metadata".

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Wilderness huts

[Janko Mihelić]

It's great to have new people enthusiastic about tagging.

A good side of already existing tags (alpine_hut, shelter..) is that a
mapper not very experianced in mountaineering can tag them easily without
reading 3 pages of text. Also, non-specialized renderers don't have to
think too much about them. They just put 2 kinds of icons and that's great.

I don't think experienced mountaneers and specialized renderers should
think much about those tags. They should treat alpine_huts, shelters,
wildernes_huts, and hotels as the same thing. What they should look at are
the specialized tags, and render according to them.

Of course, if there are no specialized tags, there's not much they can do
except render it as a question mark.

So in my opinion, we should start with defining specialized tags, and stop
trying to find boundaries for general terms.
My apologies in advance if I break convention or code, but I just
recently started mapping and even more recently joined the mailing list.
As a mountaineer I was very intrigued by the hut discussion and wanted
to share some of my knowledge on this area. I will however definitely
exceed the initial question in this message, since I'm more interested
in the differentiation between the tags.

Of my experience in the Alps, larger huts are operated in season and can
most often be accessed off-season as well, although this might require
you to get a key somewhere in a nearby village. Often times only a
smaller section of the hut is available off-season. Smaller unmanned
huts (like Ren? Maroufi mentioned) can be considered emergency shelters,
which rarely require a key. All huts vary in size and level of comfort.

As a user of these huts key features I'd like to know about are:
- What does it cost? (say the typical fee for an adult)
- Do members of an Alpine society (DE: 'mitglieder') get a rebate?
- Who/what operates the hut? (e.g. a certain person, a certain society)
- Are you allowed to bring and cook your own food?
- Period(s) of the hut being manned (can be multiple)
- Contact information (phone, website, address, via common tags)
- Capacity? (in number of persons both sleeping and visiting)
- Facilities (e.g. running water, toilet, mattresses, blankets,
electricity, lights)
- Cooking/heating facilities and available fuel (often times a stash of
wood is available)
- Hut book available (for writing your name whilst on trip, for
increased change of retrieval when something bad happens.
- Deposit box for money available (or will you have to pay in town)
- Last changes made to the hut (thereby determining the state of the
hut) (via common tags)
- Elevation (also via common tags)
- Way of supply (helicopter, cableway, carriers) (this helps determine
the likely cost of food and drinks) (a mapped helicopter landing site
and a mapped cableway can help determine this, reducing the need for a
tag).

Now looking at available tagging schemes, I do recognize quit some of
these parameters, but not all. In my opinion the tourism:x_hut and
shelter_type:x should be combined (or at least be clearly separated).

Depending on the tagging options, I believe a hut can be defined as
being all the way from a basic shelter to a small hotel, therefore
requiring a solid set of examples (from various countries) of hut
types.
Personally I'd prefer a more generic set of tags rather than having
various definitions that implicitly define location (alpine_hut), use
(emergency_shelter), type (lean_to) or level of comfort (basic_shelter).

Considering that most of the people on this mailing list are far more
experienced on tagging topics, I hope that this will fuel the discussion
necessary. Is it reasonable to start off on a new proposal as a way to
bring the huts into unison?

Kind regards,
Nico Rikken (NL)


___
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] OpenPlaques

[Andy Mabbett]

We should merge:

   Key:openplaques_plaque (27 instances)

and:

   Key:openplaques_id (293 instances)

while the latter is more widely used, the former is less ambiguous, as
OpenPlaques also has IDs for people and venues.

Do we have a process, or preferred venue, for for discussing such matters?

If we do decide on the "_plaque" variant, how do we discourage
colleagues from using "_id"?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Janko Mihelić]

2014-04-02 16:56 GMT+02:00 Andy Mabbett :

>
> There is also the case of sets;  for example, four carvings which form
> a single artwork, but which are mapped as separate entities.
>

You could put the four carvings into a relation, and put the wikidata tag
there (along with the name=* and tourism=artwork). Or you could create four
wikidata items, and give them the attribute "part of" and connect with the
first item. Then reference those four items in OSM.


2014-04-02 19:13 GMT+02:00 Andy Mabbett :

>
> One might also reasonably expect to find multiple instances of things
> like material:wikidata=Q23757 (that's limestone).
>

I wasn't talking about xxx:wikidata=* tags. There can be lots of those. All
sculptures by one artist should have the same artist:wikidata=* tag. All
streets named after Nikola Tesla should have name:etymology:wikidata=Q9036.
But there should be only one element with wikidata=Q384, or any other
number.

P.S. I'm not sure we should reference materials from Wikidata. That's going
a bit too far. Tagging material=limestone should be enough. If we want to
go that far with connecting OSM tags with Wikidata, there are better ways. I
have thought about this, and with common tags like material=* we could make
our own Wikibase installation, and connect tag combinations from OSM with
Wikidata items.

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

Re: [Tagging] Wilderness huts

[Nico Rikken]

My apologies in advance if I break convention or code, but I just
recently started mapping and even more recently joined the mailing list.
As a mountaineer I was very intrigued by the hut discussion and wanted
to share some of my knowledge on this area. I will however definitely
exceed the initial question in this message, since I'm more interested
in the differentiation between the tags.

Of my experience in the Alps, larger huts are operated in season and can
most often be accessed off-season as well, although this might require
you to get a key somewhere in a nearby village. Often times only a
smaller section of the hut is available off-season. Smaller unmanned
huts (like Ren? Maroufi mentioned) can be considered emergency shelters,
which rarely require a key. All huts vary in size and level of comfort.

As a user of these huts key features I'd like to know about are:
- What does it cost? (say the typical fee for an adult)
- Do members of an Alpine society (DE: 'mitglieder') get a rebate?
- Who/what operates the hut? (e.g. a certain person, a certain society)
- Are you allowed to bring and cook your own food?
- Period(s) of the hut being manned (can be multiple)
- Contact information (phone, website, address, via common tags)
- Capacity? (in number of persons both sleeping and visiting)
- Facilities (e.g. running water, toilet, mattresses, blankets,
electricity, lights)
- Cooking/heating facilities and available fuel (often times a stash of
wood is available)
- Hut book available (for writing your name whilst on trip, for
increased change of retrieval when something bad happens.
- Deposit box for money available (or will you have to pay in town)
- Last changes made to the hut (thereby determining the state of the
hut) (via common tags)
- Elevation (also via common tags)
- Way of supply (helicopter, cableway, carriers) (this helps determine
the likely cost of food and drinks) (a mapped helicopter landing site
and a mapped cableway can help determine this, reducing the need for a
tag).

Now looking at available tagging schemes, I do recognize quit some of
these parameters, but not all. In my opinion the tourism:x_hut and
shelter_type:x should be combined (or at least be clearly separated).

Depending on the tagging options, I believe a hut can be defined as
being all the way from a basic shelter to a small hotel, therefore
requiring a solid set of examples (from various countries) of hut
types. 
Personally I'd prefer a more generic set of tags rather than having
various definitions that implicitly define location (alpine_hut), use
(emergency_shelter), type (lean_to) or level of comfort (basic_shelter).

Considering that most of the people on this mailing list are far more
experienced on tagging topics, I hope that this will fuel the discussion
necessary. Is it reasonable to start off on a new proposal as a way to
bring the huts into unison?

Kind regards,
Nico Rikken (NL)


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

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Bryce Nesbitt]

At a road intersection, vehicle can interchange.
At a railroad intersection only one mode can use the way at a time.

A river/highway crossing is not an intersection.  The stream does not stop
for traffic. These features should not share nodes, no mater how they are
tagged.  I see no problem with a rule that says streams have implicitly
lower precedence than highways: then only exceptions like dry washes need
be tagged.

The only case where I'd created a junction between stream and highway is
for an arroyo, where in fact only one way can be used at a time (either the
stream is at low flow or the roadway is impassable).

-1 on the proposal.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ticket for JOSM to read contact metadata closed

[Dan S]

2014-04-02 18:25 GMT+01:00 Andy Mabbett :
> Not only was I disappointed to see this ticket:
>
>http://josm.openstreetmap.de/ticket/9885
>
> closed as "wontfix", but I don't understand the reason given:
>
>This format seems not to be used much.
>Too much work for too little gain.
>
> not least since I specifically referred to "an hCard microformat or
> some other contact metadata".
>
> Was I unclear in my proposal?

No, it was clear. However, when I read the ticket, my first thought
was, "That would be ideal for a josm plugin, and I don't see why
anyone would propose it for core josm rather than a plugin." I didn't
want to say it out loud and pre-empt decisions of actual josm
developers.

I know how those microformats work but I don't feel that they're very
common, so I don't have any particular problem with the reason given.
Do you feel to the contrary, that they are "used much"? Do many
business/organisation websites actually add these things?

Best
Dan

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

Re: [Tagging] Feature Proposal - RFC - drinking_water

[Bryce Nesbitt]

On Wed, Apr 2, 2014 at 1:18 PM, Rudolf Martin  wrote:

> Hi,
> according to the discussion in the mailinglist I cancel the former
> proposal "drinkable" and start a new proposal "drinking_water".


Note: There's quite an active mapping effort around drinking water:
including
use of drinking_water=yes/no as an attribute of  places like restrooms
or businesses.  There are several drinking water mapping applications
in the various app stores.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - drinking_water

[Rudolf Martin]

Hi,

according to the discussion in the mailinglist I cancel the former 
proposal "drinkable" and start a new proposal "drinking_water".

We can transfer "drinkable=" to "drinking_water=". The future tagging-
scheme will have only one tag to indicate the existence and quality of 
drinking water.

In the future the tag "drinkable=" can be deprecated.

Comments are welcome.

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

Re: [Tagging] Feature Proposal - RFC - drinkable

[Rudolf Martin]

Hi,

according to this discussion I cancel the former proposal "drinkable" 
and start a new proposal "drinking_water".

We can transfer "drinkable=" to "drinking_water=". The future tagging-
scheme will have only one tag to indicate the existence and quality of 
drinking water.

In the future the tag "drinkable=" can be deprecated.

Comments are welcome.

Rudolf




Am 27.02.2014 07:18:57 schrieb(en) Rudolf Martin:
> Hallo,
> 
> the tag "drinkable=" is used more than 3000 times.
> 
> Up today there is no clear definition about the values of this tag.
> 
> I made a proposal with some possible values, according to some 
> discussions in this mailinglist and some threads in the osm forum.
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/drinkable
> 
> Feel free to discuss.
> 
> Rudolf
> 
> ___
> 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] Ticket for JOSM to read contact metadata closed

[André Pirard]

On 2014-04-02 19:37, Tobias Knerr wrote :
> On 02.04.2014 19:25, Andy Mabbett wrote:
>> (...) I don't understand the reason given:
>>
>>This format seems not to be used much.
>>Too much work for too little gain.
>>
>> not least since I specifically referred to "an hCard microformat or
>> some other contact metadata".
>>
>> Was I unclear in my proposal?
> I don't think you were unclear. The response probably refers to the fact
> that, unfortunately, very few business websites offer contact data in a
> machine-readable format.
>
> Therefore such a feature could only be used very rarely, making it hard
> to justify the implementation effort.
>
> However, all hope is not lost: This functionality would be ideal for a
> JOSM plugin. And it's not unheard of that popular plugins later make it
> into JOSM itself.
Or, if a JOSM plugin is not your cup of tea, a small script, e.g. perl
or python, that would wget the Web page, extract the data (regexp
recommended), and write a simple *.OSM XML file containing the tags.
That file can be imported in a layer and copied to your element with
that brand new tag copy&paste.

BTW, I was more lucky with bug #9864
 that tacked my long dated,
wontfixed request onto another complaint: now, friends, you can
edit/delete/add tags by right-clicking them in
Windows>Tags/Memberships.  Right click the window header, use Side
buttons>Always hidden and enjoy.

Cheers,

André.







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

Re: [Tagging] What is OSM: a base layer for individual maps, or a fully featured geobased information system?

[Frederik Ramm]

Hi,

On 02.04.2014 17:20, André Pirard wrote:
>>> BUT: I asked OsmAnd to render the tag, and the
>>> answer was - quite understandable: "/Only officially supported tags will
>>> be rendered/". 

>> This is silly. How do they define "officially supported tag"? There's no
>> such thing in OpenStreetMap.

> I wonder why you find Osmand or other persons silly when they wonder
> what and how they should render of the mass we produce,

I find it silly to say "we only render officially supported tags". Not
more, not less.

> On the other hand, I wonder what the ranted expression "tagging for the
> renderer" means.

It means deliberately mapping things differently than they are on the
ground in order to achieve a desired rendering result.

> What I find silly is to tag say apartments or kayak wharf, whatever, and
> spend lots of OSM change sets trying to pick one of the well defined
> tags rendering them "not for the renderer".
> Is it silly to want those features to show other than like the invisible
> man on the recreation_ground or summer_resort among the other features
> nicely showing on that ground, and the miniature_golf not showing like
> the Adam's and Eve's orchard?

Problem is that while "wanting things to show on the map" is a strong
motivator for people, it doesn't scale - we are not far from the point
where for every feature we add to our main map we have to remove another
feature from this map. The map is already saturated with features. Still
we hope that we can motivate people to add more detail - but such
motivation must come through specialist applications and maps, and not
be defined by "this shows on the main map and this doesn't".

> *render=<**wikimedia-color
> **>*

> Chaos you said?  Not.

Perhaps we should simply let people edit tiles with the Gimp ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Martin Koppenhoefer]

2014-04-02 19:40 GMT+02:00 Mike Thompson :

> A bridge that is a single node could also have a tag for length (as well
> as one for width).




yes, but it would not tell you how they are oriented, because a node has no
direction, it is a point.

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

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Martin Koppenhoefer]

2014-04-02 19:29 GMT+02:00 Mike Thompson :

> 1) How much precision/accuracy?  No real world measurement or recording
> of such measurement is exactly precise/accurate. Do you use a commercial
> grade differential GPS when surveying?  When you are create a way to
> represent a road which in reality is an arc or curve, how many nodes do you
> use?  You could increase your precision by adding more nodes.



more than positional precision I try to achieve relative accuracy, e.g. the
position of a building in respect to another, the shape of something (e.g.
if the road is straight, I do not put intermediate points), if a feature is
linear I do not represent it as a node, etc.

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

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Tobias Knerr]

On 02.04.2014 18:14, Richard Z. wrote:
> On Wed, Apr 02, 2014 at 05:59:40PM +0200, Martin Koppenhoefer wrote:
>> IMHO there is a fundamental problem to your proposal because you want to
>> connect 2 ways with a node which are in reality disjunct 
> 
> objects connected with pylons and lifts are also disjunct. So what?

Don't dismiss that argument so casually. The current rule is that the
way below the bridge should not share a node with the bridge itself.

I could imagine adding an exception to that rule if it were hard to
avoid a shared node. But in this case, it can very easily be avoided by
mapping the bridge in the same manner two million other bridges have
already been added: as a way.

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

Re: [Tagging] Ticket for JOSM to read contact metadata closed

[John Packer]

You should ask the developer for clarifications.

But personally I agree with him. The effort to develop this functionality
wouldn't be worth it.
I don't think any website I added until now had contact metadata. Most
people probably wouldn't even know this feature existed if it did.
As far as I know, you can always develop a JOSM plugin (or hire someone to
do so) if you need it.


2014-04-02 14:25 GMT-03:00 Andy Mabbett :

> Not only was I disappointed to see this ticket:
>
>http://josm.openstreetmap.de/ticket/9885
>
> closed as "wontfix", but I don't understand the reason given:
>
>This format seems not to be used much.
>Too much work for too little gain.
>
> not least since I specifically referred to "an hCard microformat or
> some other contact metadata".
>
> Was I unclear in my proposal?
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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] simple_brunnel : one node bridge like xing highway over waterway

[Mike Thompson]

>
>   In most cases we already reduce the width of roads to 0 as they are not
> represented by areas.



> no, their geometric representation is a line, but their width is (or can
be) added with a tag like width and lanes, of which the latter defaults to
2 (for non-
> links) if not added explicitly.

A bridge that is a single node could also have a tag for length (as well as
one for width).  I am not suggesting this, just pointing out that tags
could be added to other geometries to denote additional dimensions. The
point is we have chosen to use geometry that does not have width to
represent a real world object that does.  Also, in many cases the width tag
is is not used on roads.





On Wed, Apr 2, 2014 at 11:29 AM, Mike Thompson  wrote:

> > We aim at precision/accuracy (IMHO, at least I do),
> 1) How much precision/accuracy?  No real world measurement or recording
> of such measurement is exactly precise/accurate. Do you use a commercial
> grade differential GPS when surveying?  When you are create a way to
> represent a road which in reality is an arc or curve, how many nodes do you
> use?  You could increase your precision by adding more nodes.
> 2) In general, there is a cost to increased precision (and accuracy) in
> terms of the survey effort, the survey equipment, the recording effort, and
> the computing resources.
> 3) At some point the value of increased precision ceases to grow, and may
> even decline.
>
>
>
>
> On Wed, Apr 2, 2014 at 10:33 AM, Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>> 2014-04-02 18:16 GMT+02:00 Mike Thompson :
>>
>> > It is also a significant loss of detail because you reduce the length
>>> of the bridge to 0
>>> Maps are abstractions. They don't represent reality precisely.
>>>
>>
>>
>>
>> We aim at precision/accuracy (IMHO, at least I do), you can always create
>> more abstracted maps from precise geodata, while the other way round it is
>> not possible.
>>
>>
>>
>>>   In most cases we already reduce the width of roads to 0 as they are
>>> not represented by areas.
>>>
>>
>>
>> no, their geometric representation is a line, but their width is (or can
>> be) added with a tag like width and lanes, of which the latter defaults to
>> 2 (for non-links) if not added explicitly.
>>
>>
>>
>>
>>>  The question should be whether the value of the data is significantly
>>> degraded if some very short bridges are represented as nodes.
>>>
>>
>>
>> OK. Can you explain how long a "very short bridge" should be? What is the
>> benefit of this kind of mapping style?
>> In this context I'd like to point out that GPS precision is not the
>> limit, you do not have to take 2 waypoints at the beginning and end of the
>> bridge and the result will become your bridge, automatically, usually you
>> will interpret these waypoints and will estimate the bridge length and
>> represent it according to your estimate, so I do not think a 3 meters long
>> bridge will result in a 45 meters long zigzag in your mapping, just because
>> you had bad GPS reception under the tree canopy and made a break on the
>> bridge ;-)
>>
>>
>> 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] Ticket for JOSM to read contact metadata closed

[Tobias Knerr]

On 02.04.2014 19:25, Andy Mabbett wrote:
> (...) I don't understand the reason given:
> 
>This format seems not to be used much.
>Too much work for too little gain.
> 
> not least since I specifically referred to "an hCard microformat or
> some other contact metadata".
> 
> Was I unclear in my proposal?

I don't think you were unclear. The response probably refers to the fact
that, unfortunately, very few business websites offer contact data in a
machine-readable format.

Therefore such a feature could only be used very rarely, making it hard
to justify the implementation effort.

However, all hope is not lost: This functionality would be ideal for a
JOSM plugin. And it's not unheard of that popular plugins later make it
into JOSM itself.

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

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Mike Thompson]

> We aim at precision/accuracy (IMHO, at least I do),
1) How much precision/accuracy?  No real world measurement or recording of
such measurement is exactly precise/accurate. Do you use a commercial grade
differential GPS when surveying?  When you are create a way to represent a
road which in reality is an arc or curve, how many nodes do you use?  You
could increase your precision by adding more nodes.
2) In general, there is a cost to increased precision (and accuracy) in
terms of the survey effort, the survey equipment, the recording effort, and
the computing resources.
3) At some point the value of increased precision ceases to grow, and may
even decline.




On Wed, Apr 2, 2014 at 10:33 AM, Martin Koppenhoefer  wrote:

>
> 2014-04-02 18:16 GMT+02:00 Mike Thompson :
>
> > It is also a significant loss of detail because you reduce the length of
>> the bridge to 0
>> Maps are abstractions. They don't represent reality precisely.
>>
>
>
>
> We aim at precision/accuracy (IMHO, at least I do), you can always create
> more abstracted maps from precise geodata, while the other way round it is
> not possible.
>
>
>
>>   In most cases we already reduce the width of roads to 0 as they are not
>> represented by areas.
>>
>
>
> no, their geometric representation is a line, but their width is (or can
> be) added with a tag like width and lanes, of which the latter defaults to
> 2 (for non-links) if not added explicitly.
>
>
>
>
>>  The question should be whether the value of the data is significantly
>> degraded if some very short bridges are represented as nodes.
>>
>
>
> OK. Can you explain how long a "very short bridge" should be? What is the
> benefit of this kind of mapping style?
> In this context I'd like to point out that GPS precision is not the limit,
> you do not have to take 2 waypoints at the beginning and end of the bridge
> and the result will become your bridge, automatically, usually you will
> interpret these waypoints and will estimate the bridge length and represent
> it according to your estimate, so I do not think a 3 meters long bridge
> will result in a 45 meters long zigzag in your mapping, just because you
> had bad GPS reception under the tree canopy and made a break on the bridge
> ;-)
>
>
> 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

[Tagging] Ticket for JOSM to read contact metadata closed

[Andy Mabbett]

Not only was I disappointed to see this ticket:

   http://josm.openstreetmap.de/ticket/9885

closed as "wontfix", but I don't understand the reason given:

   This format seems not to be used much.
   Too much work for too little gain.

not least since I specifically referred to "an hCard microformat or
some other contact metadata".

Was I unclear in my proposal?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Andy Mabbett]

On 2 April 2014 15:56, Andy Mabbett  wrote:
> On 2 April 2014 13:47, Janko Mihelić  wrote:
>
>> "There shouldn't be more than one Openstreetmap item with the same Wikidata
>> ID."
>>
>> Although that's not entirely possible.
>
> There is also the case of sets

One might also reasonably expect to find multiple instances of things
like material:wikidata=Q23757 (that's limestone).

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Eugene Alvin Villar]

On Wed, Apr 2, 2014 at 1:47 AM, Janko Mihelić  wrote:

> 2014-04-02 0:46 GMT+02:00 Eugene Alvin Villar :
>
>
>> I'm not so sure about operator:wikidata=* (or wikidata:operator=* as
>> suggested on the wiki talk page) and the other similar tags like that. I
>> think this should be discussed more since the current set of proposed
>> supplementary tags seem like an arbitrary set. Why these (operator, brand,
>> artist, etc.) and not others? If we can conceivably tag other properties
>> with Wikidata entities, we should have a more generalized scheme for adding
>> such tags.
>>
>
> What do you suggest?
>
> I think these tags are essential because the wikidata tag should be used
> very carefully. People are probably going to start tagging McDonalds
> restaurants with wikidata=Q38076 .
> That is (maybe not so obviously) wrong because that little restaurant isn't
> a multinational company. It's a restaurant that uses their franchise.
>
> That's why there should be several predefined tags so we don't end up with
> lots of bad data.
>
> operator:wikidata is better IMHO because you can also have
> operator:source, operator:webpage, and it makes more sense to do it in that
> order.
>

I would suggest that a requirement for a foo:wikidata=* tag (or
wikidata:foo=* tag) is that foo=* is already an established tag. After all,
the point of linking to Wikidata in the first place is we want a semantic
way of indicating an entity.

For example, there are lots of things named McDonald's and this makes
something like name=McDonald's or brand=McDonald's ambiguous. But by
linking to a particular McDonald's in Wikidata, we specify exactly which
McDonald's we are talking about.

Thus, I think that brand:wikidata=* or operator:wikidata=* is a semantic
version of brand=* and operator=*. So, foo:wikidata=* makes a lot of sense
if we already have foo=* in the first place.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Martin Koppenhoefer]

2014-04-02 18:16 GMT+02:00 Mike Thompson :

> > It is also a significant loss of detail because you reduce the length of
> the bridge to 0
> Maps are abstractions. They don't represent reality precisely.
>



We aim at precision/accuracy (IMHO, at least I do), you can always create
more abstracted maps from precise geodata, while the other way round it is
not possible.



>   In most cases we already reduce the width of roads to 0 as they are not
> represented by areas.
>


no, their geometric representation is a line, but their width is (or can
be) added with a tag like width and lanes, of which the latter defaults to
2 (for non-links) if not added explicitly.




>  The question should be whether the value of the data is significantly
> degraded if some very short bridges are represented as nodes.
>


OK. Can you explain how long a "very short bridge" should be? What is the
benefit of this kind of mapping style?
In this context I'd like to point out that GPS precision is not the limit,
you do not have to take 2 waypoints at the beginning and end of the bridge
and the result will become your bridge, automatically, usually you will
interpret these waypoints and will estimate the bridge length and represent
it according to your estimate, so I do not think a 3 meters long bridge
will result in a 45 meters long zigzag in your mapping, just because you
had bad GPS reception under the tree canopy and made a break on the bridge
;-)


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

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Mike Thompson]

> It is also a significant loss of detail because you reduce the length of
the bridge to 0
Maps are abstractions. They don't represent reality precisely.   In most
cases we already reduce the width of roads to 0 as they are not represented
by areas.  The question should be whether the value of the data is
significantly degraded if some very short bridges are represented as nodes.

Mike


On Wed, Apr 2, 2014 at 9:59 AM, Martin Koppenhoefer
wrote:

>
> 2014-04-02 16:41 GMT+02:00 Richard Z. :
>
>  have something revolutionary simple in my sleeve for the case where
>> a highway is going over a waterway:
>>
>>
>> https://wiki.openstreetmap.org/wiki/Talk:Key:bridge#Simple_one-node_brunnels_for_way_over_waterway
>>
>> We have been thinking about it for a while and it seems there is
>> some demand which could justify it.
>>
>
>
> you mean, let's go a step back if we can't convince really everybody to
> map according to the standards? ;-)
> IMHO there is a fundamental problem to your proposal because you want to
> connect 2 ways with a node which are in reality disjunct (and then you will
> "fix" it with a tag that explains that there is no connection). I do not
> believe that this will make things easier, my guess is that inventing
> exceptions like this will confuse mappers and blur the idea of our
> topological model.
> It is also a significant loss of detail because you reduce the length of
> the bridge to 0.
>
> cheers,
> Martin
>
> ___
> You call it brunnel, I'd call it tudge ;-)
>
>
>
>
>
> ___
> 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] simple_brunnel : one node bridge like xing highway over waterway

[Richard Z.]

On Wed, Apr 02, 2014 at 05:59:40PM +0200, Martin Koppenhoefer wrote:
> 2014-04-02 16:41 GMT+02:00 Richard Z. :
> 
> > have something revolutionary simple in my sleeve for the case where
> > a highway is going over a waterway:
> >
> >
> > https://wiki.openstreetmap.org/wiki/Talk:Key:bridge#Simple_one-node_brunnels_for_way_over_waterway
> >
> > We have been thinking about it for a while and it seems there is
> > some demand which could justify it.
> >
> 
> 
> you mean, let's go a step back if we can't convince really everybody to map
> according to the standards? ;-)

there is more to the motivation if you read the RATIONALE part.

> IMHO there is a fundamental problem to your proposal because you want to
> connect 2 ways with a node which are in reality disjunct 

objects connected with pylons and lifts are also disjunct. So what?

> It is also a significant loss of detail because you reduce the length of
> the bridge to 0.

as explained in the rationale the dimensions of the bridge/culvert are 
frequently
only a fraction of the achievable precision. Think of a track crossing a small
creek in a forest valley int the mountains. The GPS precision will be 10 meters
if you are lucky, the brunnel 2-3m.
Mapping this the old fashioned way will produce junk data, not precision.

Richard

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

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Martin Koppenhoefer]

2014-04-02 16:41 GMT+02:00 Richard Z. :

> have something revolutionary simple in my sleeve for the case where
> a highway is going over a waterway:
>
>
> https://wiki.openstreetmap.org/wiki/Talk:Key:bridge#Simple_one-node_brunnels_for_way_over_waterway
>
> We have been thinking about it for a while and it seems there is
> some demand which could justify it.
>


you mean, let's go a step back if we can't convince really everybody to map
according to the standards? ;-)
IMHO there is a fundamental problem to your proposal because you want to
connect 2 ways with a node which are in reality disjunct (and then you will
"fix" it with a tag that explains that there is no connection). I do not
believe that this will make things easier, my guess is that inventing
exceptions like this will confuse mappers and blur the idea of our
topological model.
It is also a significant loss of detail because you reduce the length of
the bridge to 0.

cheers,
Martin

___
You call it brunnel, I'd call it tudge ;-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What is OSM: a base layer for individual maps, or a fully featured geobased information system?

[André Pirard]

On 2014-03-30 13:50, Frederik Ramm wrote :
> Hi,
>
> On 29.03.2014 13:41, nounours77 wrote:
>> BUT: I asked OsmAnd to render the tag, and the
>> answer was - quite understandable: "/Only officially supported tags will
>> be rendered/". 
> This is silly. How do they define "officially supported tag"? There's no
> such thing in OpenStreetMap.
>
> I suspect the what the OsmAnd people really mean is "we can't render
> every little thing else the map becomes unreadable". Which certainly is
> correct but at the same time means they will have their own rules and
> ideas about what to show and what not.
>
> (If you should be under the impression that once a tag has gone through
> a proposal it will magically show up on openstreetmap.org then you're
> wrong.)
>
I prefer the expression "well defined tag" (by wiki or per se) rather
than "officially supported" (what support? how official?).

I wonder why you find Osmand or other persons silly when they wonder
what and how they should render of the mass we produce, after it has
been said on this list: there is no need to make proposals, just go
ahead tagging as you feel it and discuss that among your mates.

On the other hand, I wonder what the ranted expression "tagging for the
renderer" means.
According to its latest revision, that is "making a tagging mistake to
obtain some rendering".
OK, OK, but what then is "a tagging mistake" if everybody "have their
own rules and ideas about what to show and what not", and  "have their
own rules and ideas about what to tag and how" in a not very "well
defined manner"?
Are those persons silly too?

What I find silly is to tag say apartments or kayak wharf, whatever, and
spend lots of OSM change sets trying to pick one of the well defined
tags rendering them "not for the renderer".
Is it silly to want those features to show other than like the invisible
man on the recreation_ground or summer_resort among the other features
nicely showing on that ground, and the miniature_golf not showing like
the Adam's and Eve's orchard?


To solve that issue, I make the following suggestion (not proposal
because you said it's unnecessary):

*render=<**wikimedia-color
**>*

That may win the shortest definition contest. Almost...
Alas, it applies only to fill areas, but that's prominent need, let
alone the tightrope walker's show.
Any similar idea for ways and nodes welcome.
Together with name=* written inside, it's the essential for map readers
to find their way.
Chaos you said?  Not.
It's agreed that any time the other tags will produce another rendering,
it will supersede render=*.
Up to the renderer.
I think it needs no : or other prefix as it's perfectly
general (and as mapnik supports *osmarender:render*=no
 ;-))

Any comments, ±1 or +100 welcome.

Cheers,

André.



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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Andy Mabbett]

On 2 April 2014 13:47, Janko Mihelić  wrote:

> "There shouldn't be more than one Openstreetmap item with the same Wikidata
> ID."
>
> Although that's not entirely possible.

There is also the case of sets;  for example, four carvings which form
a single artwork, but which are mapped as separate entities.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Andy Mabbett]

On 2 April 2014 13:05, nounours77  wrote:

> Very interesting and important discussion.

Thank you.

> Are you all aware of that one of the main subjects of the next wikimedia 
> hackthon in May in Zurich is about this? Maybe it is interesting to discuss 
> this subject in Zurich?

Yes; unfortunately I was not able to secure a scholarship to attend.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

[Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Richard Z.]

Hi,

I have something revolutionary simple in my sleeve for the case where 
a highway is going over a waterway:

https://wiki.openstreetmap.org/wiki/Talk:Key:bridge#Simple_one-node_brunnels_for_way_over_waterway

We have been thinking about it for a while and it seems there is
some demand which could justify it.

Richard


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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Janko Mihelić]

2014-04-02 15:35 GMT+02:00 Martin Koppenhoefer :

>
> it isn't practical to create them for all streets, but my guess is it
> would well be doable for all streets with a wikidata correspondent. The
> same for rivers (where it would be generally desirable to have a common
> object, as these have to be split for several reasons, e.g. at language
> borders because of the changing name-tag).
>

Ok, I agree. Then we can set it in stone: only one unique "wikidata=Q*" tag
per database. If a Wikidata item is about two real-world entities, create a
relation in OSM (if it's in the spirit of OSM tagging) or make new Wikidata
items which can be sub-items of the main Wikidata item.

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Ilpo Järvinen]

On Wed, 2 Apr 2014, Richard Z. wrote:

> On Wed, Apr 02, 2014 at 03:53:25PM +0300, Ilpo Järvinen wrote:
> > On Wed, 2 Apr 2014, Dave Swarthout wrote:
> > 
> > > C'mon guys. Tagging an entire river at layer=-1 is simply not the way to 
> > > do
> > > things, unless it is a covered river or one that runs underground. What
> > > other possible justification is there other than not wanting to do the 
> > > work
> > > of tagging bridges with a layer=1? If you argue it's okay if there aren't
> > > any crossing/overlapping objects do you mean on the entire planet?
> > 
> > C'mon guys. It should be done with sensible defaults rather than forcing 
> > mappers to tell such plain obvious things. Rivers tend to pretty 
> > universally go below bridges, don't you agree?
> 
> yes. It should be done with sensible presets, we can not change the defaults
> for features that are already in use for ages.

This is just misinformation. The default is possible to add even though 
many keep repeating it's impossible. We just need to ensure that the 
layer=* overrides and weights more than the default. Together it would 
ensure that _only_ those cases which do not have layers defined yet get 
affected.

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Richard Z.]

On Tue, Apr 01, 2014 at 11:21:51PM -0700, Bryce Nesbitt wrote:

> April 1st aside: the number of important implicit assumptions is relatively
> small.  Rivers under, power lines over, closed ways under except if they're
> tagged building, etc.  Currently this type of layering is implicit in
> various bits rendering software, but
> it could be formalized at the tag definition level to help meet certain
> mapper expectations.

there are some more assumptions, rivers are visible and not under forests, 
residential
areas maybe others.
The way mapnik handles this is black magic.

Also, when formalizing this we should make a distinction between rendering
order and vertical object relations.

> In the case of the river/highway layer warning: if the warning had never
> existed, chances are the various workaround schemes would never have come
> up.  Rivers would run under roadways, and tagging would be needed only in
> the rare case of a ford or an arroyo with no culvert.

That warning is indeed the cause of lots of hassle. It is not wrong but
until it is balanced by more complete validation of layers, rivers etc
it seems to cause more damage than good.

Richard

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Richard Z.]

On Wed, Apr 02, 2014 at 03:53:25PM +0300, Ilpo Järvinen wrote:
> On Wed, 2 Apr 2014, Dave Swarthout wrote:
> 
> > C'mon guys. Tagging an entire river at layer=-1 is simply not the way to do
> > things, unless it is a covered river or one that runs underground. What
> > other possible justification is there other than not wanting to do the work
> > of tagging bridges with a layer=1? If you argue it's okay if there aren't
> > any crossing/overlapping objects do you mean on the entire planet?
> 
> C'mon guys. It should be done with sensible defaults rather than forcing 
> mappers to tell such plain obvious things. Rivers tend to pretty 
> universally go below bridges, don't you agree?

yes. It should be done with sensible presets, we can not change the defaults
for features that are already in use for ages.

Richard

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Pieren]

On Wed, Apr 2, 2014 at 3:10 PM, Ilpo Järvinen  wrote:

> > Rivers tend to pretty universally go below bridges, don't you agree?
>
> Or bridges go above rivers? :-)

^^
Sounds like the glass being half empty or half full. We will never
reconcile the two points of view ;-)

Pieren

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Martin Koppenhoefer]

2014-04-02 15:10 GMT+02:00 Ilpo Järvinen :

> Definately, both :), which was my point. Adding layer in this case is just
> to satisfy some lawyer rather than useful "work".
>




not adding layer tags to objects crossing on different layers is incomplete
data. It can still be rendered "correctly" in most cases, i.e. the "simple"
ones, but this doesn't make the data complete. I agree it is often more a
formal requirement then a practical necessity to tag the bridge with
layer=1 (can be guessed correctly according to common sense for 99.9% of
the cases, agreed), while tagging the river for longer parts with layer=-1
will most probably lead to inconsistencies sooner or later, so I see it as
bad style (though not necessarily "wrong").


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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Martin Koppenhoefer]

2014-04-02 14:47 GMT+02:00 Janko Mihelić :

> For example, one street is often made of several parts that have the same
> name. If we were strict with that rule, we would use relations for all
> streets (which isn't practical).



it isn't practical to create them for all streets, but my guess is it would
well be doable for all streets with a wikidata correspondent. The same for
rivers (where it would be generally desirable to have a common object, as
these have to be split for several reasons, e.g. at language borders
because of the changing name-tag).

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Jo]

Since the person buried there is mentioned in name, maybe we should also
have name:wikidata? person:wikidata or tomb:wikidata would also be better
choices than subject, I guess.

Polyglot


2014-04-02 15:17 GMT+02:00 Tobias Knerr :

> On 02.04.2014 12:24, Jo wrote:
> > I've been experimenting with wikidata tagging in OSM a bit lately. One
> > doubt I have is when tagging tombstones with subject:wikidata. Is that
> > correct?
>
> wikipedia:subject is mentioned on the German wiki page
> https://wiki.openstreetmap.org/wiki/Friedhofmapping
> (graveyard mapping, has no English equivalent unfortunately). So
> "subject" would appear to be at least a common choice.
>
> Of course there's the problem when you have a tombstone with artwork
> that depicts some real or mythical person who would also be a candidate
> for "subject" ...
>
>
>
> ___
> 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 - Wikidata

[Tobias Knerr]

On 02.04.2014 12:24, Jo wrote:
> I've been experimenting with wikidata tagging in OSM a bit lately. One
> doubt I have is when tagging tombstones with subject:wikidata. Is that
> correct?

wikipedia:subject is mentioned on the German wiki page
https://wiki.openstreetmap.org/wiki/Friedhofmapping
(graveyard mapping, has no English equivalent unfortunately). So
"subject" would appear to be at least a common choice.

Of course there's the problem when you have a tombstone with artwork
that depicts some real or mythical person who would also be a candidate
for "subject" ...



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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Ilpo Järvinen]

On Wed, 2 Apr 2014, Nelson A. de Oliveira wrote:

> On Wed, Apr 2, 2014 at 9:53 AM, Ilpo Järvinen  
> wrote:
> > C'mon guys. It should be done with sensible defaults rather than forcing
> > mappers to tell such plain obvious things. Rivers tend to pretty
> > universally go below bridges, don't you agree?
> 
> Or bridges go above rivers? :-)

Definately, both :), which was my point. Adding layer in this case is just 
to satisfy some lawyer rather than useful "work".

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Jo]

In order to apply the name:etymology:wikidata=Q... tags, I created
associatedStreet relations for most cases.

Polyglot


2014-04-02 14:47 GMT+02:00 Janko Mihelić :

> 2014-04-02 13:46 GMT+02:00 Matthijs Melissen :
>
> Is the assumption that one Wikidata object should correspond to at
>> most one OSM object? If so, it would be good to make that assumption
>> explicit.
>>
>
> I wrote exactly that here:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata#wikidata.3D.2A
>
> "There shouldn't be more than one Openstreetmap item with the same
> Wikidata ID."
>
> Although that's not entirely possible. The reason is that our rule "one
> object per entity" isn't always enforced. For example, one street is often
> made of several parts that have the same name. If we were strict with that
> rule, we would use relations for all streets (which isn't practical). So if
> there was a Wikidata entry for a street, there should be a Wikidata tag on
> every street part.
>
> Janko
>
> ___
> 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] layer=-1, rivers, bridges and tunnels

[Nelson A. de Oliveira]

On Wed, Apr 2, 2014 at 9:53 AM, Ilpo Järvinen  wrote:
> C'mon guys. It should be done with sensible defaults rather than forcing
> mappers to tell such plain obvious things. Rivers tend to pretty
> universally go below bridges, don't you agree?

Or bridges go above rivers? :-)

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Ilpo Järvinen]

On Wed, 2 Apr 2014, Dave Swarthout wrote:

> C'mon guys. Tagging an entire river at layer=-1 is simply not the way to do
> things, unless it is a covered river or one that runs underground. What
> other possible justification is there other than not wanting to do the work
> of tagging bridges with a layer=1? If you argue it's okay if there aren't
> any crossing/overlapping objects do you mean on the entire planet?

C'mon guys. It should be done with sensible defaults rather than forcing 
mappers to tell such plain obvious things. Rivers tend to pretty 
universally go below bridges, don't you agree?

-- 
 i.

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Ilpo Järvinen]

On Wed, 2 Apr 2014, Martin Koppenhoefer wrote:

> 2014-04-02 13:51 GMT+02:00 Richard Z. :
>   It is not wrong by itself but there are many circumstances
>   where it
>   is plain wrong
> 
> +1, it is not wrong as long as there aren't any crossing / overlapping
> objects that have a different layer in OSM (e.g. no layer tag in OSM =
> implicit layer=0) but are physically or conceptually on the same layer in
> reality. Basically you'd have to put all these other objects as well to
> layer=-1, which in turn would most probably require you to put even more
> objects on layer=-1 and so on.

So how would bridge+layer=1 => bridge+layer=2 transition happen, given 
such a non-sense rule. Definately a road continuing is supposedly "on the 
same layer" as the previous part? Does it imply layer is cast to stone for 
the whole road network because all connections to a node are definately 
sharing the level at the node. Or what did you mean?!?


-- 
 i.

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Dave Swarthout]

C'mon guys. Tagging an entire river at layer=-1 is simply not the way to do
things, unless it is a covered river or one that runs underground. What
other possible justification is there other than not wanting to do the work
of tagging bridges with a layer=1? If you argue it's okay if there aren't
any crossing/overlapping objects do you mean on the entire planet?


On Wed, Apr 2, 2014 at 7:07 PM, Martin Koppenhoefer
wrote:

>
> 2014-04-02 13:51 GMT+02:00 Richard Z. :
>
> It is not wrong by itself but there are many circumstances where it
>> is plain wrong
>>
>
>
>
> +1, it is not wrong as long as there aren't any crossing / overlapping
> objects that have a different layer in OSM (e.g. no layer tag in OSM =
> implicit layer=0) but are physically or conceptually on the same layer in
> reality. Basically you'd have to put all these other objects as well to
> layer=-1, which in turn would most probably require you to put even more
> objects on layer=-1 and so on.
>
> cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Janko Mihelić]

2014-04-02 13:46 GMT+02:00 Matthijs Melissen :

> Is the assumption that one Wikidata object should correspond to at
> most one OSM object? If so, it would be good to make that assumption
> explicit.
>

I wrote exactly that here:
https://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata#wikidata.3D.2A

"There shouldn't be more than one Openstreetmap item with the same Wikidata
ID."

Although that's not entirely possible. The reason is that our rule "one
object per entity" isn't always enforced. For example, one street is often
made of several parts that have the same name. If we were strict with that
rule, we would use relations for all streets (which isn't practical). So if
there was a Wikidata entry for a street, there should be a Wikidata tag on
every street part.

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Martin Koppenhoefer]

2014-04-02 13:51 GMT+02:00 Richard Z. :

> It is not wrong by itself but there are many circumstances where it
> is plain wrong
>



+1, it is not wrong as long as there aren't any crossing / overlapping
objects that have a different layer in OSM (e.g. no layer tag in OSM =
implicit layer=0) but are physically or conceptually on the same layer in
reality. Basically you'd have to put all these other objects as well to
layer=-1, which in turn would most probably require you to put even more
objects on layer=-1 and so on.

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[nounours77]

Very interesting and important discussion.

Are you all aware of that one of the main subjects of the next wikimedia 
hackthon in May in Zurich is about this? Maybe it is interesting to discuss 
this subject in Zurich? Like send the worked proposal to the people there or 
something??

nounours77


See:

https://www.mediawiki.org/wiki/Zürich_Hackathon_2014  under "Maps Integration"
https://www.mediawiki.org/wiki/Zürich_Hackathon_2014/Geo_Namespace
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Richard Z.]

On Wed, Apr 02, 2014 at 10:15:39AM +0200, Pieren wrote:
> On Wed, Apr 2, 2014 at 8:32 AM, Andrew Errington  wrote:
> > I have discovered a bunch of rivers and streams with layer=-1 in my
> > local area.  In my opinion this is simply wrong,
> 
> It's not wrong. It's just another way to use the tag layer. I't not
> because other contributors don't share you opinion that they are
> wrong.

It is not wrong by itself but there are many circumstances where it
is plain wrong. As it happens in many cases where you find long rivers
and streams with layer=-1 one or more of the conditions making it
wrong are met.

Richard

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Matthijs Melissen]

On 2 April 2014 09:47, Janko Mihelić  wrote:
> I think these tags are essential because the wikidata tag should be used
> very carefully. People are probably going to start tagging McDonalds
> restaurants with wikidata=Q38076. That is (maybe not so obviously) wrong
> because that little restaurant isn't a multinational company. It's a
> restaurant that uses their franchise.

Is the assumption that one Wikidata object should correspond to at
most one OSM object? If so, it would be good to make that assumption
explicit.

I think using Wikidata would also make it easier for external parties
to link their data to OSM data. Currently that's very difficult
because OSM identifiers are not guaranteed to be stable. For example,
someone who wants to make a database of restaurant reviews could link
their reviews to the Wikidata identifier, and use that identifier to
fetch the geographic location.

If Wikidata turns out successful, in the long run we might even
migrate tags like cuisine= and wheelchair= to Wikidata (although
that's probably a license nightmare, again one of the reasons why I
dislike the current license). We might even create OSM editors that
can edit Wikidata directly transparent to the user (some fields would
be OSM fields, some fields would be Wikidata fields).

-- Matthijs

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Andy Mabbett]

On 2 April 2014 11:31, Jo  wrote:

> or rather brand:wikidata (which is already in the list)

Please see the proposal's talk page for discussion of how to order the
componets of sub-tags:

   
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Wikidata#Order_of_parts

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Andy Mabbett]

On 2 April 2014 11:24, Jo  wrote:

> I've been experimenting with wikidata tagging in OSM a bit lately. One doubt
> I have is when tagging tombstones with subject:wikidata. Is that correct?

I don't see why not; but we could use burial:wikdata=

What do you sue for the non-wikidata tag?

> Normally that one is used when an artistic image is made of someone. What if
> it's a family grave with more than one 'subject'?

Separate values with ";"

> What if it's only the tombstone that was possibly moved in the mean time? So
> not the actual burial place anymore?

Then the named deceased is/are definitely the "subject" of the stone.

> What I found though, is that it seems like it's necessary to create an
> article on at least one WP, to make it possible to have a notable Wikidata
> entry. This is not as easy as it seems with all the rules concerning living
> people and notability of the Wikipedias. So maybe notability on Wikidata
> should be expanded to all objects that we might want to map on OSM. i.e. if
> it's physical, it can have a qualifier in Wikidata.

The notability requirements were relaxed recently; see

https://www.wikidata.org/wiki/Wikidata:Notability

and though they won't allow for every entity mapped (we don't want an
entry in Wikidata for each house, tree or patch of grass, for
example), that should support entries for many more objects.

The key issue is to make the link wherever a wikdiata entry already
esxists for an entity in OSM, so that the richness of data available
there is linked, and thus exposed to the re-users of OSM data.

We should be able to use bots/scripts/tools to do much of this, BTW.
See .

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Jo]

or rather brand:wikidata (which is already in the list)


2014-04-02 12:24 GMT+02:00 Andy Mabbett :

> On 2 April 2014 11:08, Martin Koppenhoefer  wrote:
>
> > in the case of a Franchise operator:wikidata would
> > not be McDonald's Corp. but the company that
> > operates the small restaurant (sometimes it is McD,
> > but mostly not).
>
> Then we could use wikidata:brand=
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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 - Wikidata

[Martin Koppenhoefer]

2014-04-02 12:24 GMT+02:00 Andy Mabbett :

> Then we could use wikidata:brand=



+1, or maybe brand:wikidata? Has the advantage to have all brand referers
in one block when sorting alphabetically.

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Martin Koppenhoefer]

2014-04-02 12:24 GMT+02:00 Jo :

> What I found though, is that it seems like it's necessary to create an
> article on at least one WP, to make it possible to have a notable Wikidata
> entry.




+1, IMHO it would be desirable to have the possibility to create wikidata
entries also for stuff that hasn't an own wikipedia article. Sometimes
there will also be wp articles covering more subjects / topics in one
article, where for wikidata it would be nicer not to have a 1:1
relationship data - articles.

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

Re: [Tagging] Issues relating to URIs and tagging

[Andy Mabbett]

On 2 April 2014 10:49, Andy Mabbett  wrote:

> It should be posisble to give JOSM (or other editors)
> the URL of a "contact us" web page, and for JOSM
> to then go to that page, read an hCard microformat
> (or some other contact metadata) and bring it back
> into the preset dialogue for editing and confirmation.
>
> It should also be able to do that with a Wikidata URL
> or "Q" identifier, and bring back a range of properties.
>
> I'll raise a bugs for these.

Done:

   https://josm.openstreetmap.de/ticket/9885

   https://josm.openstreetmap.de/ticket/9886

respectively.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Andy Mabbett]

On 2 April 2014 11:08, Martin Koppenhoefer  wrote:

> in the case of a Franchise operator:wikidata would
> not be McDonald's Corp. but the company that
> operates the small restaurant (sometimes it is McD,
> but mostly not).

Then we could use wikidata:brand=

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Jo]

I've been experimenting with wikidata tagging in OSM a bit lately. One
doubt I have is when tagging tombstones with subject:wikidata. Is that
correct? Normally that one is used when an artistic image is made of
someone. What if it's a family grave with more than one 'subject'?
What if it's only the tombstone that was possibly moved in the mean time?
So not the actual burial place anymore?

I do think it's important to be specific and quite a few of our OSM objects
have several references to Wikidata.

What I found though, is that it seems like it's necessary to create an
article on at least one WP, to make it possible to have a notable Wikidata
entry. This is not as easy as it seems with all the rules concerning living
people and notability of the Wikipedias. So maybe notability on Wikidata
should be expanded to all objects that we might want to map on OSM. i.e. if
it's physical, it can have a qualifier in Wikidata. It is further
complicated by the lack of freedom of panorama in Belgium and France,
otherwise it would be enough to add pictures of the objects to Commons and
create a category for them. (statues and buildings which don't get their
own WP pages for example)

Polyglot


2014-04-02 12:08 GMT+02:00 Martin Koppenhoefer :

>
> 2014-04-02 10:47 GMT+02:00 Janko Mihelić :
>
> I think these tags are essential because the wikidata tag should be used
>> very carefully. People are probably going to start tagging McDonalds
>> restaurants with wikidata=Q38076 .
>> That is (maybe not so obviously) wrong because that little restaurant isn't
>> a multinational company. It's a restaurant that uses their franchise.
>>
>> That's why there should be several predefined tags so we don't end up
>> with lots of bad data.
>>
>> operator:wikidata is better IMHO because you can also have
>> operator:source, operator:webpage, and it makes more sense to do it in that
>> order.
>>
>
>
> +1
> Still in the case of a Franchise operator:wikidata would not be McDonald's
> Corp. but the company that operates the small restaurant (sometimes it is
> McD, but mostly not).
>
> 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 - Wikidata

[Martin Koppenhoefer]

2014-04-02 10:47 GMT+02:00 Janko Mihelić :

> I think these tags are essential because the wikidata tag should be used
> very carefully. People are probably going to start tagging McDonalds
> restaurants with wikidata=Q38076 .
> That is (maybe not so obviously) wrong because that little restaurant isn't
> a multinational company. It's a restaurant that uses their franchise.
>
> That's why there should be several predefined tags so we don't end up with
> lots of bad data.
>
> operator:wikidata is better IMHO because you can also have
> operator:source, operator:webpage, and it makes more sense to do it in that
> order.
>


+1
Still in the case of a Franchise operator:wikidata would not be McDonald's
Corp. but the company that operates the small restaurant (sometimes it is
McD, but mostly not).

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Janko Mihelić]

2014-04-02 6:10 GMT+02:00 André Pirard :

>
> The last URL I used for OSM is  http://www.palogne.be  and I would like
> to know how I can find the corresponding Wikidata ID to go alongside.
>

That's one of the strengths of  Wikidata over Wikipedia. In wikidata you
just have to make a new item, give it a name and there you go. You can link
it from OSM. You can add a few attributes in Wikidata that can supplement
the data in OSM.

In Wikipedia you have to write the whole article, add pictures, and hope
that administrators won't remove it because it has no significance, or
isn't written well enough.

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

Re: [Tagging] Issues relating to URIs and tagging

[Andy Mabbett]

On 2 April 2014 03:58, André Pirard  wrote:

> I opened a JOSM bug saying that many presets
> lack the Website tag box where to enter an URL.

It should be posisble to give JOSM (or other editors) the URL of a
"contact us" web page, and for JOSM to then go to that page, read an
hCard microformat (or some other contact metadata) and bring it back
into the preset dialogue for editing and confirmation.

It should also be able to do that with a Wikidata URL or "Q"
identifier, and bring back a range of properties.

I'll raise a bugs for these.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Andy Mabbett]

On 2 April 2014 05:10, André Pirard  wrote:

> Practically, if I click "item with ID Q1722", the first impression is
>
> A script on this page may be busy, [...]

Likely a transient issue, with causes which may be at either end of
the connection.

> then quite a dump of seemingly computer savvy data (OK with me but 
> frightening many).

Work is already in hand to improve the visual display; but the main
benefits will accrue through machine interactions.

> I suppose that it should be formatted differently, but I'd like to see how to 
> have an opinion.

Try the same "Q" value in Reasonator:

   http://tools.wmflabs.org/reasonator/?q=Q1722

> On the other hand, Wikipedia is fast and pretty and, as indeed I often want 
> to switch to Дубровник for more interesting data and a challenge to 
> understand I click ru in the left pane.

While Wikipedia has some machine readable data, it has nowhere near
the machine-readability that Wikidata has.

For one example of the utility of Wikidata, see the examples at:

   http://googleknowledge.github.io/qlabel/

> The last URL I used for OSM is  http://www.palogne.be  and I would like to 
> know how I can find the corresponding Wikidata ID to go alongside.

Look for a Wikipedia article  - in any language. If there is none, it
may be that the Wikidata entry has not yet been created, If so, write
one, and then create it!

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Janko Mihelić]

2014-04-02 0:46 GMT+02:00 Eugene Alvin Villar :

>
> I'm not so sure about operator:wikidata=* (or wikidata:operator=* as
> suggested on the wiki talk page) and the other similar tags like that. I
> think this should be discussed more since the current set of proposed
> supplementary tags seem like an arbitrary set. Why these (operator, brand,
> artist, etc.) and not others? If we can conceivably tag other properties
> with Wikidata entities, we should have a more generalized scheme for adding
> such tags.
>

What do you suggest?

I think these tags are essential because the wikidata tag should be used
very carefully. People are probably going to start tagging McDonalds
restaurants with wikidata=Q38076 .
That is (maybe not so obviously) wrong because that little restaurant isn't
a multinational company. It's a restaurant that uses their franchise.

That's why there should be several predefined tags so we don't end up with
lots of bad data.

operator:wikidata is better IMHO because you can also have operator:source,
operator:webpage, and it makes more sense to do it in that order.

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Pieren]

On Wed, Apr 2, 2014 at 8:32 AM, Andrew Errington  wrote:
> I have discovered a bunch of rivers and streams with layer=-1 in my
> local area.  In my opinion this is simply wrong,

It's not wrong. It's just another way to use the tag layer. I't not
because other contributors don't share you opinion that they are
wrong.

Pieren

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