Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Janko Mihelić
pon, 26. lis 2020. u 18:13 Justin Tracey  napisao je:

>
> Another thing worth addressing in the proposal is how this relates to
> public transit systems. Things like a ferry that require a ticket for
> entry might translate pretty directly, but what about bus or light rail
> systems where you buy your ticket at a shop=ticket (or similar) to ride
> anywhere on the system? Does this apply to those too? What about systems
> where you can buy a ticket on a bus, but the ticket is also good for
> transfers to the light rail or subway stations that require a ticket for
> entry? The answer could be "no, don't use this for entire transit
> systems", but either way, public transit is prominent enough in OSM that
> I think it's worth explicitly addressing it in the proposal (and
> discussing here, if need be).
>

I was thinking about public transit while I wrote this proposal, and I
think it's more or less compatible. I was also thinking about motorways and
vignettes you have to buy at a shop. But I decided to not include those
because it would open a can of worms, and the proposal would never see the
light of day. My plan is to roll out this proposal for simpler use cases,
and if that works, we can apply it to public transport and maybe motorways.

You're right, I'll add a line in the wiki that this shouldn't be used for
public transport or motorway payment for now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Janko Mihelić
pon, 26. lis 2020. u 15:20 Jeroen Hoek  napisao je:

> On 26-10-2020 13:44, Janko Mihelić wrote:
>
> I would use a separate role for the poi (point-of-interest) itself, so
> data consumers know what the subject of the relation is (the poi), where
> its places of admission (entrances) are, and where tickets are issued.
>

I have a feeling the poi role is a bit vague. I would keep it optional,
with only admission and issue being required for the admission relation to
work.

For example, your restaurant example, if the restaurant is poi, and one
entrance is admission, what if someone adds a second entrance and forgets
to add it to the admission relation? Then the system breaks down, and the
router routes you through the second entrance.
I would keep it simple, and add the whole restaurant as admission.

But I'm sure there are examples where a third role would be necessary. I'd
like to keep this for a different proposal, and keep it simple for now.


For neatness and extensibility, perhaps admission:issue:* can be used as
> namespace for these? Data consumers then know that any admission:issue:*
> key means tickets can be got there, and you can document the common
> types (e.g., admission:issue:website, admission:issue:phone,
> admission:issue:roaming=yes (or something like that, for the roaming
> ranger edge case)).
>

I like this one. So in addition to relation members with the "issue" role,
you can also get the ticket through all the admission:issue:xxx=* ways.
I'll add it to the wiki.

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


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Janko Mihelić
ned, 25. lis 2020. u 16:16 Martin Koppenhoefer 
napisao je:

> as an additional datapoint
> shop=ticket is the only one with significant usage: (15000)
>
> https://taginfo.openstreetmap.org/search?q=ticket#values
>
> From its definition, it could also not be suitable (unclear), or maybe it
> is?
>
> https://wiki.openstreetmap.org/wiki/Tag%3Ashop%3Dticket
>
> vending=admission_tickets also has some usage: (189)
>
> https://taginfo.openstreetmap.org/search?q=admission#values
>
> and rarely
> ticket=admission (10 times)
>

I think these are prime candidates for this tag. I think any amenity can be
a place where you get issued a ticket. There could be a restaurant that
gives you keys for the tennis court it owns. I think that is also a case
where you can use this tag. You just add admission:token=keys. That way you
see a tennis court on OsmAnd, click it, and it directs you to the
restaurant, and says you need to get a key.

Although, ticket=admission sounds redundant.

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


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Janko Mihelić
It's easy to see how we would tag simple cases, like a cinema and a ticket
shop. Just add a relation, type=admission, cinema gets the role
"admission", and the ticket shop gets the role "issue".

The question is, how do we tag edge cases.
For example, a big amusement park. In my opinion, there should be a
relation with all the turnstiles with role "admission", and all the ticket
offices with role "issue". The amusement park in general doesn't even need
to be in the relation. All the other private entrances should be tagged
access=private or something like that. So the router can only route through
the turnstiles, and then, if it knows how to read the admission relation,
it sees that first you need a ticket.
Although, now that I think of it, you can add the whole theme park to the
relation, and add role "admission", that doesn't hurt.

Another example is a big nature park. There is one or two official
entrances, but you can just hike to that park without seeing any entrances
or boards that say "You have to have a ticket". There is a possibility you
buy a ticket from a ranger you accidentally meet. So do we put all the
paths in that park in the relation? Or is putting the whole park boundary,
and the oficial entrances enough?

With ski resorts, you would need to put all the aerialways in the relation
as "admission", and ticket shops as "issue". You don't put the ski slopes
or the whole ski resort with admission, because you can still hike through
there, you just can't use the ski lifts.

Does this sound good to you all? Are there more edge cases?

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


Re: [Tagging] Proposal for admission=* tag

2020-10-25 Thread Janko Mihelić
On Sun, Oct 25, 2020, 12:59 Martin Koppenhoefer 
wrote:

> An alternative idea could be to use the type=site relation, add the ticket
> office with an appropriate role to the relation (e.g. "sells_tickets").
> Maybe the term "sells" should be omitted, because sometimes you need a
> ticket, but it is free (e.g. to control the number of people you let in, or
> to get an idea how many people have entered, even if there aren't safety
> reasons).
>

Maybe admission_issuer. But you also need a role for the place you need an
admission for. You probably wanted to add it in a site relation so you
don't have two relations, but I think it would just generate problems.
Maybe I'm wrong. That could be a separate proposal.

If we do this, I would prefer a strong relation between the feature and the
> ticket office, not just by the name, but with explicit links (a relation).
>

Relations are definitely safer, but I wanted to add a unique name version
for new editors that are intimidated by relations.
Also for cases when you would have a lot of admission issuers, so we don't
get some humongous relations. Maybe there's a venue for which you can buy a
ticket in any kiosk in town. I would rather tag something like that with a
admission:name=* than add all kiosks to a relation.

Thanks for your opinion!

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


Re: [Tagging] Feature Proposal - RFC - parking=street_side

2020-10-24 Thread Janko Mihelić
sub, 24. lis 2020. u 15:14 Paul Allen  napisao je:

> Variant 1. Extend the parking area out to the roat it is on.  Pretty much
> as
> you handled the lay-by example.  As far as rendering goes, where most
> carto renders the road on top of the parking area, it represents things
> as a way that matches reality.  Here's one I did years ago.
>
>
> https://www.openstreetmap.org/?mlat=52.08560=-4.65830#map=19/52.08560/-4.65830
> Streetview for comparison:  https://goo.gl/maps/R7Q1RUWGziLaMemW8
>
> A data purist on the list objected to that.  The rendering is a good
> representation of reality but if a data consumer were to look at the
> data rather than the rendering then he or she would assume the
> car could be parked perpendicular to the carriageway with half
> the car blocking traffic.  So for purists...
>
> Variant 2.  Map the precise boundary of the parking area.  Connect it
> to the carriageway with highway=service + area=yes.  This results
> in rendering that is an even better (if slightly uglier) representation of
> reality at the expense of extra effort.  Here's one I did a few weeks
> ago to test the idea.
>
>
> https://www.openstreetmap.org/?mlat=52.08268=-4.66461#map=19/52.08268/-4.66461
> Streetview for comparison: https://goo.gl/maps/YHTv9dDvSbm6DL1A8  The
> streetview is somewhat misleading as recent aerial imagery shows clear
> surface marking delineating the boundaries.  That's also a weird example
> because some of it is off-carriageway and some on-carriageway (turn 180
> degrees in streetview and move forward to see), a situation your proposal
> doesn't cater to.
>

These two variants are mapping for the renderer, and both add false data.
The first one extends the parking over half the road. The second creates a
service road area over half the road. There is no service road area there,
you are just trying to connect the parking to the road so it looks nice on
the map. And it does look nice, but it's false data.

If we want to describe how you get onto street side parking, and it's not
obvious, we could use additional tags, like parking_entrance_direction=*.

Street side parking is a very different parking area from a big enclosed
surface parking. Some people may find it hard to park there because you
back up onto traffic, and they may want to avoid parking there. This
information is definitely very useful.

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


[Tagging] Proposal for admission=* tag

2020-10-24 Thread Janko Mihelić
Here is my proposal on the wiki:
https://wiki.openstreetmap.org/wiki/Proposed_features/Admission

In short, we don't have any way to connect places that need a ticket for
entrance, with the place that sells those tickets. Usually those places are
close together, but sometimes they are not.
In those cases, it would be nice that a router could either show us this
information, or route us to the ticket issuer first, and then to the
original place we were going to.

The tags I proposed would be:
access=admission for the place that needs a ticket
admission=issue for the place that sells the ticket
admission:to=* to tag both with the same name, so we can link them, or
relation type=admission that connects the two places.

What do you think?

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


Re: [Tagging] Feature Proposal - RFC - parking=street_side

2020-10-24 Thread Janko Mihelić
I support parking=street_side, this is a much needed tag.

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


Re: [Tagging] Feature Proposal - RFC - electricity:source

2020-09-30 Thread Janko Mihelić
I don't like the tag key, because I would assume it's saying where its
electricity is coming from, the grid or a generator on premises. This is a
very intangible thing we are putting in a tag. A business is promising it's
going to have a certain kind of contract with its electricity supplier.
Maybe, electricity:supplier:renewable=yes?
electricity:contract:renewable=yes?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (Chapel of rest)

2020-09-24 Thread Janko Mihelić
On Mon, Sep 21, 2020, 22:16 Peter Elderson  wrote:

> I have heard mourning chapel, mourning room, funeral chapel, funeral room.
> Chapel of rest does not seem right to me, though I understand how the
> funeral business would like that term better.
>
> But I'm not a native speaker. PCMIIW.
>

I tried to google images of all these terms. They all find the right thing,
although IMHO images of chapel of rest and mourning room are most
concentrated and on the target.

But I'm also not a native speaker.

Janko

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


Re: [Tagging] Best practices regarding implied tags

2020-09-21 Thread Janko Mihelić
On Mon, Sep 21, 2020, 16:00 Martin Koppenhoefer 
wrote:

> if it is a power pole, why would you remove the utility tag?
> When there’s a highway=track and you remove the tracktype tag the object
> also will still be correctly tagged :)
>

You're right, I meant the whole information is still there. Oneway=no says
"I was there, and it's definitely twoway" so if you remove that tag, you
lose that. But I feel you lose nothing when you remove usage=power, because
it adds no additional meaning or even meta information. Everybody knew its
usage was power.

I would never remove the tag, I was just talking about tags in general.

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


Re: [Tagging] Best practices regarding implied tags

2020-09-21 Thread Janko Mihelić
There are a lot of big power towers that carry an optical communications
line together with the power lines. Would that be
utility=power;communication?

Adding specific implied information is not wrong, but data consumers
shouldn't rely on them. If someone changes utility=power to
utility=communication;power, or if someone outright deletes the utility
tag, that power pole is still correctly tagged.

Janko

ned, 20. ruj 2020. u 20:30 Paul Johnson  napisao je:

>
>
> On Sun, Sep 20, 2020 at 11:58 AM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> The previous responses are focusing on the benefit of adding
>> explicit tags in situations where the current tagging is ambiguous.
>>
>> Certainly there is a benefit of adding "oneway=no" on all two-way roads
>> and "oneway=yes" on motorways to make the situation explicit.
>>
>> But the original question was about whether or not we should add
>> "man_made=utility_pole" + "utility=power" to current power poles.
>>
>
> Well, does narrow it down from a neighborhood pole that might have cable
> television or carry the PSTN.
> ___
> 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] Fwd: Documenting historic=anchor to the historic wiki page

2020-09-08 Thread Janko Mihelić
This is getting very metaphysical, and tags have been invented to be as
practical as possible for the mapper [1]. If someone sees an old anchor on
the ground, one of the first things that's going to pop into their mind is
historic=anchor. That has happened 40 times, separately by several mappers
all over the world (including me). I just wanted to document this tagging
because it made sense to me.

Historic=memorial + memorial=anchor has been used 20 times, but my tagging
instinct said that maybe it's better to have a use case for anchors that
are not memorials. If people think memorial=anchor is better, that's ok
with me. But i'm not ok with creating a complicated ontology with
tourism=artwork because no one will naturally come to that tag while on the
field. Flowerbeds and fountains are also made just to be nice, but it's not
tagged as artwork, because it doesn't look like artwork, and doesn't quack
like artwork.

Janko

[1] - https://wiki.openstreetmap.org/wiki/Duck_tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Fwd: Documenting historic=anchor to the historic wiki page

2020-09-08 Thread Janko Mihelić
This is getting very metaphysical, and tags have been invented to be as
practical as possible for the mapper [1]. If someone sees an old anchor on
the ground, one of the first things that's going to pop into their mind is
historic=anchor. That has happened 40 times, separately by several mappers
all over the world (including me). I just wanted to document this tagging
because it made sense to me.

Historic=memorial + memorial=anchor has been used 20 times, but my tagging
instinct said that maybe it's better to have a use case for anchors that
are not memorials. If people think memorial=anchor is better, that's ok
with me. But i'm not ok with creating a complicated ontology with
tourism=artwork because no one will naturally come to that tag while on the
field. Flowerbeds and fountains are also made just to be nice, but it's not
tagged as artwork, because it doesn't look like artwork, and doesn't quack
like artwork.

Janko

[1] - https://wiki.openstreetmap.org/wiki/Duck_tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Fwd: Documenting historic=anchor to the historic wiki page

2020-09-08 Thread Janko Mihelić
This is getting very metaphysical, and tags have been invented to be as
practical as possible for the mapper [1]. If someone sees an old anchor on
the ground, one of the first things that's going to pop into their mind is
historic=anchor. That has happened 40 times, separately by several mappers
all over the world (including me). I just wanted to document this tagging
because it made sense to me.

Historic=memorial + memorial=anchor has been used 20 times, but my tagging
instinct said that maybe it's better to have a use case for anchors that
are not memorials. If people think memorial=anchor is better, that's ok
with me. But i'm not ok with creating a complicated ontology with
tourism=artwork because no one will naturally come to that tag while on the
field. Flowerbeds and fountains are also made just to be nice, but it's not
tagged as artwork, because it doesn't look like artwork, and doesn't quack
like artwork.

Janko

[1] - https://wiki.openstreetmap.org/wiki/Duck_tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Documenting historic=anchor to the historic wiki page

2020-09-08 Thread Janko Mihelić
This is getting very metaphysical, and tags have been invented to be as
practical as possible for the mapper [1]. If someone sees an old anchor on
the ground, one of the first things that's going to pop into their mind is
historic=anchor. That has happened 40 times, separately by several mappers
all over the world (including me). I just wanted to document this tagging
because it made sense to me.

Historic=memorial + memorial=anchor has been used 20 times, but my tagging
instinct said that maybe it's better to have a use case for anchors that
are not memorials. If people think memorial=anchor is better, that's ok
with me. But i'm not ok with creating a complicated ontology with
tourism=artwork because no one will naturally come to that tag while on the
field. Flowerbeds and fountains are also made just to be nice, but it's not
tagged as artwork, because it doesn't look like artwork, and doesn't quack
like artwork.

Janko

[1] - https://wiki.openstreetmap.org/wiki/Duck_tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Documenting historic=anchor to the historic wiki page

2020-09-07 Thread Janko Mihelić
pon, 7. ruj 2020. u 22:15 Paul Allen  napisao je:

> In that case it would not be historic, just a random anchor put there
> because
> it looks pretty.  Possibly tourism=artwork, but I'm not sure what would
> be a suitable artwork_type.  It's not really an installation or a
> sculpture.
> It's really "found art" in the broader definition of the term.  Has/had
> another purpose but has been appropriated as art.
>

Why do you think it's different from a historic=cannon?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Documenting historic=anchor to the historic wiki page

2020-09-07 Thread Janko Mihelić
pon, 7. ruj 2020. u 21:28 Paul Allen  napisao je:

> Sounds like a memorial to me. So maybe historic=memorial +
> memorial=anchor.
>

Anchors are often not a memorial, just an anchor put somewhere because it
looks nice. You can search for images of "anchors on display" [1]. I guess
this would be a better image:

https://commons.wikimedia.org/wiki/File:Kotwica_SS_Pozna%C5%84.JPG

Most of them aren't even marked, they just stand there. Something like a
historic=cannon [2].

[1] - https://www.google.com/search?q=anchor+on+display=isch
[2] - https://wiki.openstreetmap.org/wiki/Tag:historic%3Dcannon
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Documenting historic=anchor to the historic wiki page

2020-09-07 Thread Janko Mihelić
Historic=anchor would be an anchor from a historic ship displayed as a
public memorial. An example:
https://commons.wikimedia.org/wiki/File:Arizona_anchor_bolin_plaza.JPG

There aren't many of these tags right now, 38 in total. I found info on
about 10 of those, and they all fitted the description above.

I intend to put this description and picture on the historic page, in the
Values table:

https://wiki.openstreetmap.org/wiki/Key:historic#Values

 Everybody ok with this?

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


Re: [Tagging] Adding mapillary tags to every building

2020-06-19 Thread Janko Mihelić
Let's hope the license will be permissive enough for other projects to take
the data and continue their own way. They only said it will be free for
commercial use, but it didn't say free as in beer or what. They said:

> By continuing to make all images uploaded to Mapillary open, public, and
> available to everyone
>

Which is pretty vague.

pet, 19. lip 2020. u 13:42 Martin Koppenhoefer 
napisao je:

>
>
> sent from a phone
>
> > On 19. Jun 2020, at 11:20, European Water Project <
> europeanwaterproj...@gmail.com> wrote:
> > For how long ?
>
>
> for as long as Facebook wants. There is also the practical aspect: even if
> the license is permissive, it doesn’t imply you can actually get the data
> for downloading.
>
> Facebook has changed conditions of their services in the past, let’s
> recall their whatsapp acquisition where they promised it would remain
> “independent” from the rest of Facebook and where they then
> combined/unified their messenger services under the same hood some years
> later. If history has told us one thing, it’s not to trust facebook (IMHO
> not even as far as you’re able to throw them)...
>
> 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] Adding mapillary tags to every building

2020-06-08 Thread Janko Mihelić
On Fri, Jun 5, 2020, 14:27 Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Wikimedia Commons has no notability requirements, see
> https://commons.wikimedia.org/wiki/Commons:Project_scope
>
> It is perfectly fine to upload things like that there.
>

Ok, you convinced me. Photos of buildings are even more notable then photos
of bicycle parking, so I'll try and take photos of a few buildings and see
how that goes.

I probably won't be creating a category for each building, so then I will
be linking to those pictures with the image=* tag, right?

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


Re: [Tagging] Adding mapillary tags to every building

2020-06-05 Thread Janko Mihelić
On Thu, Jun 4, 2020, 16:48 European Water Project <
europeanwaterproj...@gmail.com> wrote:

> While all three of them have shown enthusiasm, single-snap images are just
> not a priority at this point for Mapillary.
>

This is interesting. Did they say that they don't prefer single-snap images
in the database, or that they aren't planning to put any effort into
developing single-snap software?

 Our goal is to move all our images to wikimedia commons.
>

Aren't water fountains not notable enough for their database?

I love your project!

Janko

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


Re: [Tagging] Adding mapillary tags to every building

2020-06-04 Thread Janko Mihelić
>
> Is it really necessary? "give image for location [lat, lon] from direction
> X" seems a
> basic functionality for service like Mapillary.
>

I almost never found a photo of something I was looking for with OsmAnd's
"close by Mapillary photos". I think Osmand only takes Mapillary photos x
meters from the subject. The compass and gps  inside mobile phones aren't
good enough for this to work this easily. Directions of photos are often
wrong. Maybe if we wait some 5-10 years for neural networks to understand
the surroundings, and decide which photos show the subject.

And a second point is there are a lot of low quality photos, shot behind
the dashboard, and others, shot specifically for that building, framing it
just right, on a nice sunny day. I don't think there is going to be an
algorithm that decides which photo is nicer.

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


[Tagging] Adding mapillary tags to every building

2020-06-04 Thread Janko Mihelić
I think having a photo of every building, as well as other features like
public sculptures, memorials, bus stations would be very useful. You would
be able to click a building, and know what it looks like.

I had an idea to make an app that shows you a map, and you would click on a
building, take a photo which would go to Mapillary, take the ID of the
photo, and put it in OSM in a mapillary=* tag. Since there is an app that
does a very similar thing, StreetComplete, I made a suggestion to add that
functionality. But the dev told me that makes no sense, taking a photo of
every building makes no sense because it's too much. Here's the issue:

https://github.com/westnordost/StreetComplete/issues/1883

If he doesn't want that in his app, that's ok, but my question is, does
this community think this would be ridiculous or not? Would Mapillary be
the right service to host the photos? I thought I would suggest this same
functionality to OsmAnd because they already use Mapillary to show close by
photos of a feature, but now I'm not sure if OSM would even want this. I
think this would be a big advantage over other map databases.

Thanks for the opinion!

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


Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-20 Thread Janko Mihelić
On Fri, Mar 20, 2020, 15:21 Dave F via Tagging 
wrote:

> True. There is no requirement for public_transport tags. PTv2 adds
> nothing new.


Maybe for tags, but relations with the order of platforms and ways was new
if I recall correctly, and we should still use that (well, the platforms,
maybe not ways). I remember the early relations with the "forward" and
"backwards" roles which would break each time someone reversed a way.

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


Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-09 Thread Janko Mihelić
As an avid public transportation mapper, I welcome the PTv3. It has all the
features I need, and it will reduce maintenance by a lot.

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


Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

2019-12-06 Thread Janko Mihelić
pet, 6. pro 2019. u 19:39 Kevin Kenny  napisao je:

> What about the case where it's perfectly right and proper to walk the
> way in either direction, but the route is signed in only one
> direction?
>

Religious pilgrimages come to mind, where you usually go in one direction.
But in that case, the whole route is oneway. So if you sort ways in the
relation, the same way they are sorted in public transport routes, then you
can use the established tag "signed_direction=yes"[1].

[1] - https://wiki.openstreetmap.org/wiki/Key:signed_direction
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

2019-12-06 Thread Janko Mihelić
I think the "forward" and "backward" don't belong in a role of a relation.
Oneway=yes on a way should be enough. In the Wiki discussion it is said
that if there is one little "oneway" way in a big branch, then all the ways
in a branch should be checked to see if the whole branch is oneway. But
that means we are doing the work of a router directly in the tags.

We should just mark "oneway" ways as such, and leave the rest to the
routers.

Also, "main" and "alternative" are orthogonal to "forward" and "backward".
We should then have "main:forward", "alternative:backward", and so on. That
doesn't make sense, and is not what "role" is traditionally used for.
Public transport routes used to use them, but not in the new scheme.

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


Re: [Tagging] Real time in public transport

2019-11-19 Thread Janko Mihelić
There is a mailing list for public transport, it's
talk-tran...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

And I don't understand the intention. Do you mean a tag for a URL to the
timetable of a line?

uto, 19. stu 2019. u 13:24 A A  napisao je:

> Hello everyone.
>
> What do you think about the possibility of standardizing the use of a url
> in "departures_board" or "passenger_information_display" tags to be able to
> report arrival times in real time at a stop or train / subway / bus station?
>
> I think it can be very useful information. If it is added in a simple way
> through a tag, it could be easily implemented by mapping and navigation
> software and used for navigation in public transport or simply for querying
> the waiting time at a specific stop or public transport station.
> ___
> 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] Roman roads - was Re: "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-14 Thread Janko Mihelić
I think it's enough for a road to have a roughly similar route to be called
a Roman road.

I think the tag historic=roman_road or historic=road should at least
resemble something historic. If only the route is historic, then adding
something like historic=route to the type=route relation might be better.


On Sat, Sep 14, 2019, 20:22 Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 13. Sep 2019, at 19:42, Paul Allen  wrote:
> >
> > BTW, a better way for marking Roman roads would be to use
> historic=roman_road.  It's a
> > lapsed proposal, and doesn't show even on lutz's historic places map,
> but it would allow
> > a simple overpass-turbo query and might even let you map them with uMap
> (going by
> > the amount of data in just one Roman road, that's probably
> impracticable, though).  It's
> > been used 2000 times, so you could probably use it without a formal
> proposal.
>
>
> yes, or historic=road with historic:civilization=ancient_roman
>
> I’ve used both variants in the past but just had a second thought: is this
> about roads that are still with the original paving or also applicable to
> roads that were built by the romans but now have different paving (and
> maybe are wider, and maybe even left the original position for small parts)?
>
>
> 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] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-14 Thread Janko Mihelić
What I got out of this discussion is, part:wikidata will probably not be
widely used, but people still agree that most of the wikidata tags that are
on multiple OSM objects are wrongly tagged. So maybe the right way is to go
case by case, and see how to deal with them.

For example, a lot of rails and motorways have all ways tagged with the
same wikidata tag, in addition to the relation. I feel a lot of us think
that only the relation should be left with the wikidata tag. I will be
going through the taginfo list[1], and be unifying those tags. Is that ok
for the majority here?

I could also make a wiki page of "What not to tag with wikidata=*" and put
these two examples there.

Then later we can expand that list with consensus.

[1] - https://taginfo.openstreetmap.org/keys/wikidata#values
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-13 Thread Janko Mihelić
pet, 13. ruj 2019. u 17:31 Paul Allen  napisao je:

> On Thu, 12 Sep 2019 at 09:45, Janko Mihelić  wrote:
>
> The correct way to group them is with a relation.  If we don't have a
> suitable type of  relation then propose one.
>

My idea was to expand the general "part:wikidata=*" to more specific tags.
For example, give all peaks and ridges of a mountain the
mountain:wikidata=* tag, instead of part:wikidata=*. Part is just the
first, nondescript step. If we decide on a better tag, we replace the
part:wikidata with the new XXX:wikidata=*


> I think the only sensible solution is to delete the wikidata tags from
> *all* of them.
>

I definitely agree with this. But I'm not going to be the one who does it
:) It's bad mapping, but it's still somewhat useful information.

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


Re: [Tagging] mesh bicycle network

2019-09-12 Thread Janko Mihelić
I don't think this is good mapping. Firstly, this is not a route. A route
is something that gets you from one place to another. This is a network of
routes, and there is a tag for it, type=network[1] But this type of a
relation breaks the "Relations are not Categories" rule [2]. That's why I
think this network relation should be broken up into route relations with
the appropriate network tag.

If this is allowed, then what stops someone from making a "Bicycle routes
in Germany" relation ?


[1] - https://wiki.openstreetmap.org/wiki/Relation:network
[2] -
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

čet, 12. ruj 2019. u 11:05 Martin Koppenhoefer 
napisao je:

>
>
> sent from a phone
>
> > On 12. Sep 2019, at 10:49, Peter Elderson  wrote:
> >
> > If there is agreement that this actually is something worth mapping, I
> don't see a problem there.
>
>
> this is how wikipedia works, in OpenStreetMap you do not need approval of
> others that something is “worth” mapping, the osm question is whether
> something is verifiable.
>
>
> 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] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-12 Thread Janko Mihelić
One problem

On Thu, Sep 12, 2019, 06:53 Mateusz Konieczny 
wrote:

>
> I still see no benefit in using part:wikipedia
> or part:wikidata over current version.
>

One problem with the current system is that if you click one of those
dwarfs in OSM, and see it's linked to an object in wikidata, you have no
way of seeing if that is the whole wikidata object, or just a part of that
object, unless you download the whole OSM database. Or if you are a human,
and you look at the wikipedia article, and see there should be a whole
bunch of dwarfs. But that example doesn't seem as important.

Currently, the second most numerous wikidata tag in OSM is
https://www.wikidata.org/wiki/Q2961670, an item that describes all the
roman roads in historic Gaul in France. All those ways, close to 500 of
them, have wikidata=Q296167. That is obviously not good tagging. But how do
you differentiate good wikidata tagging from bad tagging? I think this rule
and part:wikidata are the way to clean this up. I would give all these
roads part:wikidata=Q29616, and than that looks much closer to reality.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-11 Thread Janko Mihelić
čet, 12. ruj 2019. u 00:04 Paul Allen  napisao je:

> In this case, I'm not convinced that we couldn't accept a many-to-one
> mapping of ways to
> wikidata.  But if you insist, put them in a relation of some kind.  Maybe
> a type=wikidata, even,
> although I suspect that would have more problems than benefits.
>

If anything, type=street. But I think part:wikidata=* would be fine.

If a relation makes no sense, a wikidata item shared by them probably
> doesn't, either.  I'll just
> go and look at wikidata for stolperstein...
>

I agree, Stolperstein isn't a good example, memorial=stolperstein is
enough. But I remember an artwork that was tagged somewhere, and it was
consisted of several murals spread around the city. Part:wikidata=* would
be perfect for that case.

So what you want is synonymous with "fixme."  But more complicated and
> requiring more work.
> I'm not convinced this is a good idea.
>

Well, a fixme, but also a correctly tagged link with wikidata.

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


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-11 Thread Janko Mihelić
sri, 11. ruj 2019. u 20:24 Mateusz Konieczny 
napisao je:

> can you give specific example of case
> where part:wikidata would be better
> than wikidata?
>

The classic example is a street. Streets are one of those objects in OSM
which are defined by a unique name on several ways. So if a wikidata item
is about a street, all ways get the same part:wikidata=*

Art or memorial installations like Stolperstein[1], which are distributed,
but have one wikidata item. It's hard to imagine every Stolperstein will
get its own article. And a relation with all these nodes makes no sense.

And then it could be used when the mapper isn't sure how to map a wikidata
item, so she just tags all the parts with part:wikdiata=*. Then someone
more experienced shows up, and creates a valid relation, and sums up all
those parts into one wikidata=* (and deletes the part:wikidata=* tags).

[1] - https://en.wikipedia.org/wiki/Stolperstein
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-11 Thread Janko Mihelić
On Wed, Sep 11, 2019, 19:31 Martin Koppenhoefer 
wrote:

> I am also against restricting wikidata tags to a 1:1 relationship. It
> would require restructuring of specific items either in osm or in wikidata,
> or both, just to have them linked nicely (at a certain point in time,
> because from then on, they will diverge again, inevitably).
>

I agree that 1:1 isn't always possible, that's why I propose
part:wikidata=*.

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


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-11 Thread Janko Mihelić
sri, 11. ruj 2019. u 15:37 Imre Samu  napisao je:

>
> imho:  The wikidata taxonomy is in very early stage.  but we can create
> some SPARQL validating with https://sophox.org/ ;
> but this is not for the average osm editors.  it is too complex task -
> fixing wikidata and osm parallel ...
>

I agree, it won't be easy. But I also think it will be possible only if we
enforce the "unique wikidata id" rule. If we don't enforce this, and just
let the wikidata tag go it's own course, we'll get into a mess that will be
hard to dig out of.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-11 Thread Janko Mihelić
The rule I'm trying to implement, "A Wikidata item cannot be connected to
more than one OSM item", might also be interpreted as a DRY rule. But I'm
at least proposing part:wikidata, so we can have the benefits of DRY, as
well as easiness of tagging WET tags.

sri, 11. ruj 2019. u 14:59 Paul Allen  napisao je:

>
> This will come as a shock and a surprise to people on this list, but some
> open-source
> projects become obsessive about an overly-rigid interpretation of rules.
> In this case it is
> that if there is a property shared by all members of a group then it MUST
> be marked on
> the group ALONE and not also on individual members.  It doesn't matter
> that users would
> find it far more useful to be able to see that an individual saint is
> canonized, those users
> MUST be savvy enough about Wikipedia rules to know that they should then
> look at the
> parent group in order to get all the information they wish.  DRY (don't
> repeat yourself)
> is rigidly enforced.
>
> Yes, I've been bitten by this before.  Marking up Wikimedia images as
> being listed
> buildings.  All went fine until I happened to mark a few that were
> collected in a group
> of "Listed buildings in ."  Those changes were reverted because
> the
> grouping itself was flagged as being of listed buildings.  It matters not
> that when
> individual buildings are tagged the tag includes the listed building ID,
> which links
> to an external page describing the building and its reason for listing,
> whilst the
> collective tag cannot have that information.  It matters not that if you
> look at non-grouped
> listed buildings you see clearly that they are listed buildings but if you
> look at
> grouped listed buildings you have no idea that they are listed.  DRY.
> Rules is
> rules.
>
> Anyone who thinks the preceding paragraph is off-topic because it's about
> Wikimedia should try to recall all the times on this list when somebody has
> insisted that rules is rules, even when the outcome of following those
> rules is sub-optimal.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-11 Thread Janko Mihelić
sri, 11. ruj 2019. u 14:35 Martin Koppenhoefer 
napisao je:

> Why do the individual saints not have the property, but the group has it?
>

 I'm suspecting it's "tagging for the renderer". They probably have
infoboxes in the Wikipedia article, and they would like that box to show
"saint". That should be fixed if a smarter infobox comes, which would show
two boxes, or something like that. But there is nothing stopping you to add
all the right properties to the two individual saints.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-11 Thread Janko Mihelić
sri, 11. ruj 2019. u 14:34 Joseph Eisenberg 
napisao je:

> Doesn't this mean that it would be better to create separate Wikidata
> items for each separate OSM feature, rather than creating a new OSM
> tag?
>

You have examples like tagging all ways that are a part of a street with
the wikidata item about that street. You can't define those parts in
Wikidata.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-11 Thread Janko Mihelić
sri, 11. ruj 2019. u 13:04 Martin Koppenhoefer 
napisao je:

> One problem is that wikidata does not allow to have the same wikipedia
> article for several wikidata objects.
>

Yes it does. Look at this object:

https://www.wikidata.org/wiki/Q23837517

Its about one saint, Constantia, who was always mentioned together with
Felix, her saint brother. She has no wikipedia articles about her, only
about them both:

https://en.wikipedia.org/wiki/Felix_and_Constantia

and so there is a wikidata item about them both, and it has a property "has
part" which has values of Constantia and Felix objects. Constantia and
Felix have a property "part of".

So in some cases we can divide the wikidata object if it helps with
identifying the OSM object. But again, I'm not sure this is the case with
Malta, because the article is about the state, and the city is "inside" the
state. When you reference the state, you imply the city inside it. Felix
and Constantia are totally separate entities, and you don't imply one when
you reference the other.

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


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-10 Thread Janko Mihelić
pon, 9. ruj 2019. u 16:24 Mateusz Konieczny 
napisao je:

> Monaco includes for example territorial
> waters while it is not a part of the city.
> City states may include also other areas
> that is not a part of the city.
>

Then in OSM city and city-state are different things. In Wikidata we only
have an article about the city-state. This article also talks about the
city, but the overall theme is the city-state. That means, only the
admin_level=2 should get the wikidata tag. If we tagged everything that the
article describes, we could tag every entity inside the relation
(Monaco-Ville, formula race track, the port) with wikidata=Q235, and that
makes no sense. We only tag the one entity that best points to the subject
of the article.

If that is not possible, use part:wikidata=*.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-09 Thread Janko Mihelić
pon, 9. ruj 2019. u 04:26 Joseph Eisenberg 
napisao je:

> Also see Singapore: it's an island, city and country. And more?
>

It's quite obvious Q334 is not about the island, it's about the city-state.
So wikidata=334 on relation 1769123
 is just wrong. It should
be wikidata=Q1054746 .

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


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-09 Thread Janko Mihelić
>
> Monaco is a https://en.wikipedia.org/wiki/City-state


I'm not convinced. If city-state is a city and a state in one, then why do
we have two objects in Openstreetmap? Then it should be one relation with
admin_level=2 + place=city. As I understand, City-state doesn't mean it is
a dual entity, it means this is a special kind of state, that is consisted
only of one city.

But if it really is a dual entity, then this tag is made for it, put
part:wikidata=Q235 on both. But I don't think this is the case.

Janko

pon, 9. ruj 2019. u 02:58 Imre Samu  napisao je:

> >> Which OSM object will be the real "Monaco"?
> > Relation 1124039 should be  the only one with the wikidata tag.
> > It's the only one that represents the country (boundary=administrative +
> admin_level=2), which the wikipedia article is about.
> > Relation 2220322 is a city (place=city). Wikipedia article is about the
> country.
>
> imho: Monaco ( https://www.wikidata.org/wiki/Q235 )
> instance of(P31)
> - "city-state"  ->  r2220322 (place=city)
> - AND "country"->  r1124039  (country )
>
> so  1:2 relationship  ( 1 wikidata : 2 osm object)  is correct.
> Monaco is a https://en.wikipedia.org/wiki/City-state
>
>
>
>
> Janko Mihelić  ezt írta (időpont: 2019. szept. 9., H,
> 0:54):
>
>> ned, 8. ruj 2019. u 23:17 Imre Samu  napisao je:
>>
>>> the 1:1 relationship is not so easy.
>>> What is your proposal for  Monaco (Q235) ?
>>> https://www.wikidata.org/wiki/Q235
>>> now: https://taginfo.openstreetmap.org/tags/wikidata=Q235#overview
>>> - 2 nodes
>>> - 3 relations
>>> Which OSM object will be the real "Monaco"?
>>>
>>
>> Relation 1124039 <https://www.openstreetmap.org/relation/1124039> should
>> be  the only one with the wikidata tag. It's the only one that represents
>> the country (boundary=administrative + admin_level=2), which the wikipedia
>> article is about.
>> Relation 2220322 <https://www.openstreetmap.org/relation/2220322> is a
>> city (place=city). Wikipedia article is about the country.
>> Relation 36990 <https://www.openstreetmap.org/relation/36990> is land
>> area of a country (boundary=land_area). Not quite sure what it's used for,
>> but it's not a boundary of a country.
>> Nodes are helpers for label placement, which are not widely used by
>> renderers anymore.
>>
>> 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] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-08 Thread Janko Mihelić
ned, 8. ruj 2019. u 23:17 Imre Samu  napisao je:

> the 1:1 relationship is not so easy.
> What is your proposal for  Monaco (Q235) ?
> https://www.wikidata.org/wiki/Q235
> now: https://taginfo.openstreetmap.org/tags/wikidata=Q235#overview
> - 2 nodes
> - 3 relations
> Which OSM object will be the real "Monaco"?
>

Relation 1124039  should
be  the only one with the wikidata tag. It's the only one that represents
the country (boundary=administrative + admin_level=2), which the wikipedia
article is about.
Relation 2220322  is a city
(place=city). Wikipedia article is about the country.
Relation 36990  is land area
of a country (boundary=land_area). Not quite sure what it's used for, but
it's not a boundary of a country.
Nodes are helpers for label placement, which are not widely used by
renderers anymore.

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


Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-08 Thread Janko Mihelić
Has no one any opinion on this? I have a feeling this is important for the
future of the Openstreetmap - Wikidata relationship..

Janko

On Fri, Sep 6, 2019, 15:05 Janko Mihelić  wrote:

> Last year there was a little discussion about unique wikidata ids in the
> openstreetmap database:
> https://lists.openstreetmap.org/pipermail/tagging/2018-August/038249.html
>
> It was more or less decided there was no problem with this. Nevertheless,
> I think we should consider having a hard rule of "*A Wikidata item cannot
> be connected to more than one OSM item*".
>
> Problems with not enforcing this rule:
>
> - the problem of a partially downloaded database, where one is never sure
> if a wikidata item is fully downloaded unless the whole database is
> downloaded.
>
> - we could get a flood of wikidata tags where one would, for example, tag
> every building in a town with the wikidata id of the town, because that
> building is a part of the town. Is that wrong tagging? Well, if the above
> rule is not in place, I'm not sure.
>
> - if a road segment has two road routes that are using it, then we should
> tag it as "wikidata=Q1234;Q5678". That means, if we want to find any
> wikidata id, we should be prepared to parse all wikidata tags and be
> prepared for semicolons. This slows down any wikidata searches
>
> - we can't enforce some rules like "tag leisure=stadium can only be
> connected to something that is, or is derived from Q483110 (Stadium) in
> Wikidata" because, if we tag all the parts of an entity, we can also tag a
> water fountain in the stadium, because that is a part of it.
>
> So I propose we enforce this rule, and we tag, for example, railways only
> on the route relation.
>
> If one wants to tag all route segments with a wikidata tag, I propose a
> general usage "*part:wikidata=**" which would be used when a single
> wikidata tag just isn't viable. Proposal wiki page here:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/part:wikidata
>
> Thanks for reading,
> Janko Mihelić
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-06 Thread Janko Mihelić
Last year there was a little discussion about unique wikidata ids in the
openstreetmap database:
https://lists.openstreetmap.org/pipermail/tagging/2018-August/038249.html

It was more or less decided there was no problem with this. Nevertheless, I
think we should consider having a hard rule of "*A Wikidata item cannot be
connected to more than one OSM item*".

Problems with not enforcing this rule:

- the problem of a partially downloaded database, where one is never sure
if a wikidata item is fully downloaded unless the whole database is
downloaded.

- we could get a flood of wikidata tags where one would, for example, tag
every building in a town with the wikidata id of the town, because that
building is a part of the town. Is that wrong tagging? Well, if the above
rule is not in place, I'm not sure.

- if a road segment has two road routes that are using it, then we should
tag it as "wikidata=Q1234;Q5678". That means, if we want to find any
wikidata id, we should be prepared to parse all wikidata tags and be
prepared for semicolons. This slows down any wikidata searches

- we can't enforce some rules like "tag leisure=stadium can only be
connected to something that is, or is derived from Q483110 (Stadium) in
Wikidata" because, if we tag all the parts of an entity, we can also tag a
water fountain in the stadium, because that is a part of it.

So I propose we enforce this rule, and we tag, for example, railways only
on the route relation.

If one wants to tag all route segments with a wikidata tag, I propose a
general usage "*part:wikidata=**" which would be used when a single
wikidata tag just isn't viable. Proposal wiki page here:

https://wiki.openstreetmap.org/wiki/Proposed_features/part:wikidata

Thanks for reading,
Janko Mihelić
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

2019-08-04 Thread Janko Mihelić
Isn't the only thing that matters, for routing at least, the name of the
role that the platform has? I mean, anything can have the role "platform".
Highway=bus_stop can have the role platform.

And nothing renders anyway. So why don't we just start using other
public_transport values, like pole, waiting_area, and whatever we want. We
just start using them, and give them the "platform" role in the relations.
Rendering will come.

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


Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

2019-08-02 Thread Janko Mihelić
pet, 2. kol 2019. u 15:34 Markus  napisao je:

> I still see these solutions:
>
> 1. To rename public_transport=platform into public_transport=stop (or
> public_transport=waiting_area) and to abandon
> public_transport=stop_position as well as the PTv1 tags. This would have
> the advantage that bus, tram and train stations could all be tagged alike,
> that tram and bus stops would only need one element even if there is a
> platform (because railway/highway=platform + public_transport=stop could be
> combined) and that public_transport=stop_area were only needed at stations.
> Besides, new transport modes could later be added easily.
>
> 2. Same as 1, but public_transport=platform is not renamed (only
> public_transport=stop_position and PTv1 tags are abandoned). Advantages:
> same as 1; disadvantage: the misnamed public_transport=platform remains.
>
> 3. To abandon PTv2 tags, but to stick to PTv2 routes and to map
> highway=bus_stop/railway=tram_stop beside the road/rails ("Stockholm
> scheme"). Disadvantages: the same that are the advantages of 1.
>

If we removed stop_positions, that makes creating public transport
relations much easier. Just add platforms in the correct order, and then
the route in the correct order. Even better, you don't even need the route.
For public transport routing to work, you just need platforms in the
correct order, and you are done! That would make those huge bus routes with
hundreds of members that go from Croatia to Germany obsolete, and you would
only need a route with several nodes.

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


Re: [Tagging] one feature one element

2019-07-04 Thread Janko Mihelić
I've been tagging it with an empty amenity=school polygon around
everything, and then two points with amenity=school + name=* + all the
other specific tagging. But if mapped like that, a data consumer would see
3 schools. I like your solution with overlapping multipolygons.

Janko

čet, 4. srp 2019. u 09:58 Martin Koppenhoefer 
napisao je:

> The one feature page states:
>
>- More than one of something on the same site e.g. two schools sharing
>grounds. Normally if the schools are separate they would have separate
>neighbouring grounds, but if the only thing defining a separation between
>two schools is their buildings, then the containing area should be tagged
>with a suitable landuse
>=*, and the buildings
>tagged individually.
>
>
> from
>
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element#Examples_of_bad_situations
>
> I don’t believe this is common practice, e.g. there isn’t even a landuse
> value for schools.
> I would rather tag 2 schools with distinct buildings and shared grounds as
> 2 overlapping amenity=school areas with the “other buildings” (those of the
> other school) excluded via multipolygon inner roles.
>
> If we did like currently suggested in the wiki it would also loose the
> information about the grounds (only the buildings would result as schools).
>
> Cheers, Martin
>
>
> sent from a phone
> ___
> 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] Mistagging footways as highway=pedestrian

2019-02-28 Thread Janko Mihelić
čet, 28. velj 2019. u 14:15 Martin Koppenhoefer 
napisao je:

>
>
> We do not need a new tag to retag situations where highway=pedestrian is
> misused. There is already highway=footway that should be used for ways
> which are not actual "roads" but smaller.
>

I agree, but we have a practical problem with people that think that this:
https://images.mapillary.com/QQXg40ewDRF6hsi0jNGhzA/thumb-2048.jpg

cannot be tagged the same as this:
https://images.mapillary.com/53iC9URhRKV_gYsxbF4ZYw/thumb-2048.jpg

People look at the first photo as a little street, not as a footway. It
also probably has a name xx street.
Both are really footways, but the resemblance ends there. I think adding
footway=alley to the first one would make sense to people, and maybe then
they will stop with wrong tagging.

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


Re: [Tagging] Mistagging footways as highway=pedestrian

2019-02-28 Thread Janko Mihelić
I think we should add a new type of footway, and then render it the way
people like. For example, footway=alley. Wikipedia page for alley has
photos of exactly the old town streets as I believe you are talking about.
That way service=alley is reserved for American type alleys for garbage
trucks, and footway=alley is reserved for old town streets.

I looked at tag info, there are 102 footway=alley tags already.

The war plan looks like this:
1. create a wiki page for footway=alley
1. add footway=alley to old towns that managed to keep highway=footway tags,
2. reach a critical mass of tags, add rendering that is similar to
pedestrian,
3. retag pedestrian tags.

Janko


On Wed, Feb 27, 2019, 14:01 Mateusz Konieczny 
wrote:

> I created https://josm.openstreetmap.de/ticket/17391 and
> https://github.com/openstreetmap/iD/issues/5991
>
>
> Maybe this is a good idea, maybe it will be implemented and maybe it will
> help to keep control
> over situation.
>
>
> Feb 26, 2019, 3:30 PM by dieterdre...@gmail.com:
>
>
>
> Am Di., 26. Feb. 2019 um 14:40 Uhr schrieb Sergio Manzi :
>
> ... and not only cycleways: have a look here, where I live:
> https://www.openstreetmap.org/#map=15/45.4364/12.3334
>
> All are "highway=pedestrian", at the same level, but believe me: they are
> not!
>
>
>
>
> Venice is a globally unique (or maybe almost unique) exception anyway, but
> what we currently have there is the result of people reclassifying all the
> footways as pedestrian roads, even if they are 50 cm wide. I have started
> in the past several attempts to open a discussion on this, but it felt like
> Don Quixote. See this as an example:
> https://www.openstreetmap.org/way/488627565/history I have surveyed it
> myself, like many others, where I began to reclassify the very narrow
> footpaths from pedestrian to footway, but I am not local and people destroy
> the finer grained distinction of footway and pedestrian as soon as you add
> them, I guess they do not want the red dots. It is unfortunate, because it
> makes the Venice map much harder to read and less useful. If you are local,
> please try to improve the situation, we do not need new tags, it would be
> sufficient to apply the existing ones consistently rather than
> indiscriminately.
>
> 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 – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-08 Thread Janko Mihelić
I think we need to map peninsulas in three ways, as nodes, areas, and ways.

Areas when the land border is obvious. Nodes for little ones, when you
don't have time to draw an area and the shape of the peninsula is obvious.
Then there are ways, when the peninsula is huge, or when the land border
isn't obvious, like the Italian peninsula or the Peninsula of India. I made
a proposal for mapping peninsulas as ways:

https://wiki.openstreetmap.org/wiki/Proposed_features/Peninsula

Janko

On Sat, Jan 5, 2019, 23:10 Christoph Hormann  wrote:

>
> For understanding of the Florida physical geography - Cape Canaveral is
> located here
>
> https://www.openstreetmap.org/node/4887735121
>
> USGS topos identify another cape - unmapped in OSM - slightly northwest
> called the 'False Cape' (somewhat generic term for capes that are
> likely mistaken for the real thing from the sea) near here:
>
> https://www.openstreetmap.org/node/5316727559
>
> The area Cape Canaveral AFS is built on
>
> https://www.openstreetmap.org/relation/7384620
>
> is called Canaveral Peninsula (unmapped in OSM - see USGS topos as well)
> which is part of Merritt Island.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] historic=memorial tagging question

2018-10-18 Thread Janko Mihelić
Memorial=* tag is a bit broken at the moment. Its values can be both, what
the memorial looks like, and what it commemorates. So the most common value
is war_memorial, and that says what it commemorates. Almost all other
values say what it looks like, so IMHO, we should stick with the "what it
looks like" usage of the tag. Memorial=marker says more about what it
commemorates, and very vaguely, so I wouldn't use this one. I read the
stele wikipage[1] and that doesn't look right. So in my opinion, we should
invent a new value that references freestanding stone plaques. So I have a
few suggestions:

memorial=freestanding_plaque
memorial=freestanding_stone
memorial=stone_plaque
memorial=freestanding_stone_plaque

or something like that..

Janko Mihelić

[1] - https://en.wikipedia.org/wiki/Stele



On Thu, Oct 18, 2018, 05:49 John Willis  wrote:

> Thanks, but marker only has seven uses - stele has about 5000.
>
> Also- Marker, to me, would be something you would find in the ground with
> a number or a pole with a number on it, or something based around a ref
> number or value of some sort (like a mile marker).
>
> In the US, a "historical landmark" or "marker" is usually a plaque
> embedded in a pedestal or stone, so it is memorial=plaque, with about
> 10,000 uses.
>
> ^___^
>
> Javbw
>
> > On Oct 18, 2018, at 4:21 AM, EthnicFood IsGreat <
> ethnicfoodisgr...@gmail.com> wrote:
> >
> > memorial=marker
>
> ___
> 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] Fwd: OSM Wikibase is now live

2018-09-18 Thread Janko Mihelić
uto, 18. ruj 2018. u 20:13 Yuri Astrakhan  napisao
je:

> I am not sure I understood about the key+value property.  Are you asking
> for a new string property to store "key=value" of the current tag?  But
> that's already being stored as a sitelink (shown in the upper right corner).
>

That answers my question.

Each tag combination could have a wikidata link that describes what that
combination really "is". So if we make an item for combination
leisure=pitch+sport=soccer, we can put a property wikidata=Q8524[1]. That
means that someone can make a script that finds all wikidata items Q8524 on
the map. Our tags finally get a real semantic definition. That is really
exciting!

P.S. There mustn't be more than one OSM item with the same Wikidata item.
So a minimal combination of OSM tags should have the wikidata tag. For
example, in my opinion leisure=pitch+sport=soccer+surface=grass shouldn't
get the Q8524 because a pitch can have artificial grass, and it would still
be considered a football field.

[1] https://www.wikidata.org/wiki/Q8524

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


Re: [Tagging] Fwd: OSM Wikibase is now live

2018-09-18 Thread Janko Mihelić
This is wonderful news! I hope this will soon become the new principal tag
database to get semantic meaning out of OSM tags. Thank you to all involved!

And now a few questions:

Why isn't there key+value as a property? The Q888 (bridge:movable=bascule)
should have a property "Tag" which has the whole string,
"bridge:movable=bascule". That brings us to my second question:

Are there plans to have tag combinations? I have a feeling combinations are
going to be the real killer application, because only with combinations you
can connect tags and real world classes of objects. For example, a football
field can't be put in the wikibase with any one tag. We need a tag
combination, leisure=pitch + sport=soccer.
Bridge:movable=bascule is also only an attribute of a bridge, not an
instance of a movable bridge.

So I propose a new value, "instance_of":"tag_combination", and in it, we
can have two or more "Tag" properties that I proposed in the first half of
this post.

Again, thanks for making this service!

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


Re: [Tagging] 3d-tagging

2018-06-06 Thread Janko Mihelić
There is now a new way:

https://wiki.openstreetmap.org/wiki/3D_Model_Repository

I suggest using this. IMHO this is a better way to add 3d data to OSM
because you can make the model much nicer, with textures and little
details. In OSM you can add data for routing inside the building, like
doors and hallways that bring you to a wanted room.

Janko

On Thu, May 24, 2018, 21:01 Jmapb  wrote:

> Stefan, you can map a tunnel in the "Simple 3D" scheme by adding a
> "min_height=x" tag on the building:part that forms the top of the
> tunnel. I.e., if the tunnel opening is 8 meters high and the top of the
> castle wall is 4 meters above that, tag that building:part with
> height=12 and min_height=8. Of course it's up to the 3D renderer to
> support this, but I think the major ones do.
>
> J
>
>
> On 5/24/2018 7:25 AM, Stefan K. wrote:
> > Sorry, more information needed :)
> > Okay, i found https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
> > and the german https://wiki.openstreetmap.org/wiki/DE:OSM-4D
> >
> > I'm right now asking because i am wondering if there is a somehow
> > "official" one. I will try to tag a castle. I intend to use the
> > "Simple 3D Buildings" most of the time, but for a castle entry, also
> > tunnel=building_passage is needed.
> > https://wiki.openstreetmap.org/wiki/Key:tunnel
> > There is nothing for that one in Simple 3D, just in the other 4D (or
> > 3D? - got confused).
> >
> > For 3D there would be something additional needed, width, height and
> > maybe as proposed in the 3D site
> > https://wiki.openstreetmap.org/wiki/DE:3D-building/Durchfahrt an
> > additional passage_type.
> >
> > There reason i ask is, i was asking (in a wrong way) on github at
> > kendzi if he would build an support for that and he was asking, if
> > there is an accepted tagging schema.
> >
> > Hopefull its better now,
> > greetings
> >
> >
> > Zitat von PanierAvide :
> >
> >> Hello,
> >>
> >> This one is the common way to do 3D tagging on OSM :
> >> https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings
> >>
> >> It is already used by several renderers (F4Map, OSM2World...), all
> >> supported software is listed in the page.
> >>
> >> Regards,
> >>
> >> Adrien.
> >>
> >> Le 24/05/2018 à 11:01, Stefan K. a écrit :
> >>> I found a wiki for 3d-tagging, is that a proposal? Can i tag using
> >>> theses suggestet tags?
> >>> Unfortunately i could not find a 3d-mailinglist so i thought i mayb
> >>> try it here. The 3d section in the forum seems not to populated
> >>> unfortunately, i would prefer it over the mailing-list :(
> >>>
> >>> Greetings
> >>>
> >>>
> >>> ___
> >>> Tagging mailing list
> >>> Tagging@openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/tagging
> >>
> >>
> >> --
> >> PanierAvide
> >> Géomaticien & développeur
> >>
> >>
> >> ___
> >> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposed features - RFC 2 - Pressurized waterways

2018-02-20 Thread Janko Mihelić
pon, 19. velj 2018. u 19:18 François Lacombe 
napisao je:

>
> Are we talking about a new value like waterway=aqueduct ?
>

I would really like a new waterway value because the ones we have are too
restricting. "River" and "stream" cover natural waterways, and man made
values are:

1. canal - big enough to be used by boats
2. drain - for carrying superfluous water away, concrete walls
3. ditch - the same as drain but without concrete

We need a value for man made waterways that aren't used for carrying water
away, but for bringing water somewhere.

Waterway=aqueduct looks ok to me, although, in the Wikipedia page for
aqueduct, bringing water to hydro power stations is never mentioned. But I
think it's ok to use that value for that use.

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


Re: [Tagging] Public art definition

2018-01-31 Thread Janko Mihelić
On Sun, Jan 28, 2018, 10:50 Tom Pfeifer  wrote:

>
> So, how does "exhibit=artwork" work for you?
>

+1
I like that key because it could have lots of useful values, like
exhibit=animal, exhibit=car, exhibit=moon_rock, etc.

Janko

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


Re: [Tagging] Proposed features - Voting - Pressurized waterways

2018-01-23 Thread Janko Mihelić
uto, 23. sij 2018. u 16:16 François Lacombe <fl.infosrese...@gmail.com>
napisao je:

>
> To get the whole hydrographic system, users have to query waterway,
> pipeline and some other keys not all related to water.
> If all water paths would have only waterway=*, this would be simpler and
> sustainable.
> Would you be happy if I remove highway=* from tunnels or bridges just
> because it's not "natural" roads?
>
> Not to mention standard osm render doesn't currently render pipelines.
> Introducing a new value of waterway, already imported in mapnik schema may
> be simpler than adding pipeline and some extra keys.
>

Calling pipelines waterway=pressurized because it would be easier for you
to extract it and render it makes this tagging for the renderer. Tags
should be as consistent as possible for the mappers, not data consumers. If
a mapper sees a pipeline, and you tell him "tag that as
waterway=pressurized because then my SQL query can be nice and short" the
mapper is going to get annoyed and quit. If it's a pipeline, tag it as a
man_made=pipeline, and that's it. Somebody else can tag the type of a
pipeline, but nobody is suposed to think about SQL queries when mapping.

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


Re: [Tagging] Proposed features - Voting - Pressurized waterways

2018-01-23 Thread Janko Mihelić
I would like to add tunnel=headrace to the waterway=drain because that's
how they are called. Just google "headrace tunnel" and this is exactly what
you will get.

The pressurized pipeline that goes into the hydro power plant is called
"penstock":

https://en.wikipedia.org/wiki/Penstock

That's why I would like to tag those pipelines as man_made=pipeline +
pipeline=penstock. "Penstock" by itself means that the pipeline is
pressurized, but we can add "pressurized=yes" just to be safe
(waterway=pressurized is a funny tag to me).

Using waterway=drain for underground rivers is not very accurate. I think a
new waterway tag is needed here, because this is a new concept. I suggest
waterway=subterranean_river. And if it has a siphon, add
subterranean_river=syphon.

So, I made an image with my suggestions, changes are bolded and underlined
(I love your images, they are worth a thousand words :)

https://imgur.com/a/obdNd

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


Re: [Tagging] Difference between lighthouses and beacons

2018-01-19 Thread Janko Mihelić
I think the border between lighthouses and beacons can only be fuzzy, we
can never make a clear line. We can have a few pointers like "living
quarters, big in size", but nothing set in stone. And that is ok because
their purpose is the same, so some overlaping is not a problem. But I
believe we do want to differentiate between this:

http://static.panoramio.com/photos/original/44263014.jpg

and this

https://upload.wikimedia.org/wikipedia/commons/thumb/e/e5/Buoy_seal.jpg/250px-Buoy_seal.jpg

We have seamark tags that only look at their light and its properties, but
the man_made tag can look at the structure and how it looks and feels.

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


Re: [Tagging] Difference between lighthouses and beacons

2018-01-18 Thread Janko Mihelić
čet, 18. sij 2018. u 15:27 Malcolm Herring 
napisao je:

> man_made=beacon *is* the appropriate tag for such structures. Tags in
> the "seamark" namespace relate only to the *navigational function* of an
> object, not the physical form. Many beacon objects have no navigational
> function & therefore do not carry "seamark" tags.
>

Ok, so man_made=beacon is used for the physical structure that is made to
cary the light, and the seamark tags are used to define what kind of a
light is it. That looks correct.

I'm in the process of making a new icon, and I can make a pull request on
the openstreetmap-carto soon.

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


Re: [Tagging] Difference between lighthouses and beacons

2018-01-18 Thread Janko Mihelić
Ok, the discussion at least came to an agreement that this:

https://imgur.com/a/U8SXn

is not a man_made=lighthouse. We have A LOT of those mapped as lighthouses
(I think the majority of that tag is on the wrong element). One reason is
rendering, and we have to start rendering something. The question is what.

I looked at man_made=beacon. Taginfo says we have about 7 000 of those, and
the wiki shows something that resembles what we are talking about, but not
quite:

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dbeacon

Maybe just start rendering seamark=beacon? We have only about 2 000 of
those, but we have 40 000 seamark:type="beacon_lateral" or
"beacon_isolated_danger" or "beacon_special_purpose". We can add
seamark=beacon to those.

The icon would be something like man_made=lighthouse, but thinner.

sri, 17. sij 2018. u 13:09 Martin Koppenhoefer 
napisao je:

>
>
> 2018-01-16 12:36 GMT+01:00 Malcolm Herring  >:
>
>> On 16/01/2018 10:25, Andrew Davidson wrote:
>>
>>> OK. So a lighthouse has to have a rotating light then?
>>>
>>
>> A lighthouse does not have any particular type of light, or any light at
>> all, but it will have a lamp room at the top
>>
>
>
> I guess an open fire would be OK as well? Let's not forget, lighthouses
> are much older than (electric) lamps.
>
> 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] Difference between lighthouses and beacons

2018-01-14 Thread Janko Mihelić
A map with lighthouses was produced [1] that gained popularity because it
was nicely rendered, but it showed how flawed OSM data was in this regard.
Very often little beacons [2] are mapped as man_made=lighthouse, which is
not right. Lighthouses are big structures that were built to have living
quarters for people that operated them.

So a fuzzy rule can be created, you can't have a man_made=lighthouse tag
and seamark:xxx=yyy tags on the same object. That's instantly an error.
Seamark tags are used for instruments that help navigation, and lighthouses
are structures that can house those instruments. But they are not the same
thing. So a lighthouse can be an area with a seamark node at the place
where the light is.

Is this generally accepted?

Thanks,
Janko

[1] -
https://api.mapbox.com/styles/v1/planemad/cjcdq00xd3tg82rpxkl4ojwp5.html?fresh=true=true_token=pk.eyJ1IjoicGxhbmVtYWQiLCJhIjoiemdYSVVLRSJ9.g3lbg_eN0kztmsfIPxa9MQ#1.5/30.890431/51.367743/0

[2] - https://wiki.openstreetmap.org/wiki/Seamarks/Lights
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Questions on building-tag

2017-12-19 Thread Janko Mihelić
Let me show to you, the smallest cathedral in the world:

https://en.wikipedia.org/wiki/Church_of_the_Holy_Cross,_Nin

It's not the seat of a bishop any more, but it was in the past (and
churches are often called cathedrals even after they lose the status of a
seat of a bishop).

I wouldn't tag this building=cathedral, even building=church is a bit much.

Janko

uto, 19. pro 2017. u 14:19 Marc Gemis  napisao je:

> Adam, Martin,
>
> thanks for your input. It seems that one cannot only rely on what one
> sees from the street, or at least not always. Sometimes the name
> (church vs cathedral) has to be used to determine the value for
> building.
> I've seen pubs in all kind of buildings in Belgium, from being located
> in terraced houses, over train stations and villas to old manor
> houses. I doubt there is really a "pub"-building type here.
>
> I guess there will always be cases were we can debate whether a type is X
> or Y.
>
> regards
>
> m.
>
>
>
> On Tue, Dec 19, 2017 at 9:09 AM, Adam Snape 
> wrote:
> > Hi,
> >
> > My own view of the building tag is that it notes what the building looks
> > like to someone on the ground. If it's a fairly generic building then
> > obviously the current use is a fairly good indicator. Something like a
> > church or pub though often still retains the characteristics of that
> type of
> > building even when internally converted. As long as it still externally
> > looks like a church or pub that is what I tag the building as.
> >
> > Adam
> >
> > On 16 Dec 2017 4:35 p.m., "Martin Koppenhoefer" 
> > wrote:
> >>
> >> sent from a phone
> >>
> >> > On 16. Dec 2017, at 09:39, Marc Gemis  wrote:
> >> >
> >> > The building page on the wiki [1] lists e.g a church, cathedral and
> >> > chapel.
> >> > But what is the structural difference between a church and a cathedral
> >> > ? I always thought a cathedral is where a bishop leads the messes (or
> >> > something like that).
> >>
> >>
> >> yes, AFAIK a cathedral is the main church of a diocese in certain
> >> denominations like roman-catholic, it is the church where the bishop
> >> or archbishop has his seat, and it is therefore also typically the
> >> biggest and most important church of the area. Structurally you will
> >> find cathedrals in general to be bigger than other churches, although
> >> there can be pretty big churches as well. Technically, "cathedral" is
> >> more a title than a certain type, while there are specific sub-types,
> >> in particular "gothic cathedrals" (mainly in France).
> >>
> >>
> >>
> >> > The wiki page on cathedral tries to avoid this by saying some
> >> > buildings are build as cathedral but without a bishop, without saying
> >> > how one can see the difference between a cathedral and a church.
> >>
> >>
> >> I would leave this decision to the church. If they call it a cathedral
> >> it is one.
> >>
> >>
> >>
> >> > I understand that chapels can be attached to other buildings, but they
> >> > can also be free standing. But how different are the bigs ones then
> >> > from a small church ?
> >>
> >>
> >> chapels might be there for a certain purpose, e.g. on cemeteries or in
> >> baptisteries, or part of a bigger structure (even a train station, an
> >> airport, a hotel, a convent, a hospital or palace). Again, I'd go here
> >> by what it is called  by the church.
> >>
> >>
> >> > I see similar problems with rectangular buildings with one or two
> >> > entrances a couple of floors, a flat roof and a lot of windows. They
> >> > can be schools, commercial, apartments, civic buildings. I guess one
> >> > has to take the interior division into account as well to determine
> >> > the type, not ?
> >>
> >>
> >> residential buildings are typically different from administrative
> >> buildings regarding the unit size and inner organization, entrances,
> >> corridors, stairs, sanitary blocks, etc.. You won't typically have
> >> difficulties telling which kind it is, if you enter. Of course, very
> >> neutral "architecture" like containers might be usable as
> >> (construction site) offices and also as tempory emergency residence.
> >>
> >>
> >>
> >> > So can a commercial building change to a school when the interior wall
> >> > are changed? And if so, why is a church not changed into an apartment
> >> > building when the interior changes ?
> >> >
> >> > Or are we just wishing that building refers to the structure and not
> >> > the function ?
> >> > Or am I overthinking the whole topic ?
> >>
> >>
> >> yes, convertions are generally possible, it depends on economic and
> >> cultural factors if they are done. Some structures are clearly more
> >> universally usable and easier to convert into a different usage then
> >> what they were built for, compared to others. It also depends on the
> >> amount of compromise, an inhabitant is willing to accept, on the
> >> individual lifestyle (some people like living in industrial
> 

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

2017-11-30 Thread Janko Mihelić
I think permanent IDs should be done with our own Wikidata. Wikibase is a
Wikimedia extension, that means our own Wiki can install OSMData right now.
Then if you want to open a permanent ID for a shop, create a new OSMData
item, and tag the shop with OSMData=M38267 (M instead of Q, for Map).

This permanent ID won't just be an empty number, but it can have all sorts
of structured data attached to it, for example Name, so mappers can see
what that ID is about.

Of course, duplicating data would be strongly discouraged, and that can be
easily done by restricting properties that can be added to items. So
property "religion" won't be available for church items, because that
property is already expected in the OSM database.

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


Re: [Tagging] Multiple offices at the same address - (Multiple values for one key)

2017-10-29 Thread Janko Mihelić
We are arguing about a temporary state of affairs. Sooner or later,
Nominatim and others will be able to assign addresses to nodes inside a
polygon, and renderers will be able to see that the same address is
rendered 3 times. Until then we have to do what we can with what we have.
And not start making up some strange new schemes to make newcomers lifes
hell.

Just start rendering offices, and the problem is temporarily averted.

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


Re: [Tagging] airstrip vs runway

2017-10-09 Thread Janko Mihelić
I'm in favor of airstrips, but I would make airstrip a subcategory of
runway. So tagging an airstrip as runway is not wrong if you don't know any
better.

Anyway, is there a way to know if a runway is an airstrip from aerial
photos? Is grass surface enough to make something an airstrip? Does this
depend on the country/region? What if a grassy runway has a big light that
helps landing, is it a runway then? What if there is a very small fee to
land there. What's the line between them?

Janko

pon, 9. lis 2017. u 15:38 Dave Swarthout  napisao
je:

> Just to add some observations about Alaska to this conversation. Alaska
> has hundreds of long strips whose surface is gravel or grass long ago
> cleared of woods and brush that served as landing strips for small
> airplanes. The small airplane is almost as common in rural Alaska as
> automobiles are in other areas. That's a bit of an exaggeration but as I
> scan the satellite imagery I'm constantly amazed at the sheer number of
> these landing strips that are scattered here and there. And if one checks
> the USGS Topo maps as I do while adding geographical features to Alaska,
> one can see where airstrips existed in the past but when inspecting the
> location with satellite imagery, no trace of them can be found. Years ago,
> airplane and airport aficionados using sources such as "ourairports.com",
> have added hundreds (thousands?) of them to OSM as though they were actual
> airports.
>
> I also add an admission that, not being aware of any other tagging or any
> need for differentiation as to type, I've mapped dozens of these as
> runways, sometimes adding a surface tag, other times not.
>
> But they are surely different than one would expect to find at a "real"
> airport facility. The more remote variety offer no services, not even fuel,
> and are suitable for use by small planes only (bush planes). Many are
> abandoned or in need of maintenance. I would not want to give the erroneous
> impression that these runways are actually the same sort of beast an
> official airport provides.
>
> I think therefore that there is a definite need to tag such landing strips
> differently.
>
> AlaskaDave
>
>
>
> On Mon, Oct 9, 2017 at 7:47 PM, Christoph Hormann  wrote:
>
>> On Monday 09 October 2017, Martin Koppenhoefer wrote:
>> >
>> > I am not aware that OSM in any way defines what an “aircraft” is.
>> >
>> > Why is “aircraft” objective and verifiable, but “airport” is not?
>>
>> Now discussion is drifting into the ridiculous.
>>
>> Depending on your perspective it can obviously be considered inherently
>> impossible to fully define the meaning of every word of a language
>> using just words of this language.  The purpose of verbal definitions
>> is to create a consistent framework of interrelationships between the
>> words that allows you to interpret them in a way that is consistent
>> with other users of the language and identify misinterpretations
>> because they create inconsistencies.
>>
>> You used the term 'airport' in a segregative way, i.e. to distinguish
>> between runway-like features on an airport and runway-like features on
>> a non-airport.  The use of the term 'aircraft' is merely descriptive.
>> It does not not aim to distinguish runways from non-runways (runway
>> tagging according to the definition for example can be equally used for
>> runways for manned and unmanned aircrafts).
>>
>> So even if you have no real idea what an aircraft is you will probably
>> be able to mostly map runways correctly based on that definition using
>> your understanding of the terms 'air' and 'craft'.
>>
>> And in general you should as much as possible be able to decide on tags
>> based on *local* observations.  If the same runway-like feature needs
>> to be tagged differently depending on if it is located within an
>> airport of not (by whatever definition of airport) that is not a very
>> good idea for tagging.  A mapper is for example very likely able to
>> reliably identify a "strip of land on which aircraft can take off and
>> land" from high resolution imagery but specific classification of the
>> area this strip is located in can be much less reliable.
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] war_memorial

2017-10-05 Thread Janko Mihelić
On Wed, 4 Oct 2017, 16:47 Martin Koppenhoefer <dieterdre...@gmail.com>
wrote:

>
>
> sent from a phone
>
> > On 4. Oct 2017, at 14:53, Janko Mihelić <jan...@gmail.com> wrote:
> >
> > I use historic=memorial_site. There are 31 of them in OSM right now.
>
>
> I think this is fine for these cases, do you have it documented in the
> wiki?
>

No.. I've been meaning to do it for some time, but laziness prevailed.

Janko

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


Re: [Tagging] war_memorial

2017-10-04 Thread Janko Mihelić
sri, 4. lis 2017. u 01:32 Graeme Fitzpatrick 
napisao je:

> Question on memorials v monuments thanks.
>
> How about a memorial arboretum (https://en.wikipedia.org/wiki/Arboretum),
> a commemorative planted grove of trees that you can walk through & sit
> under?
>
> Does that count as a monument, or is it a memorial?
>

I use historic=memorial_site. There are 31 of them in OSM right now.

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


Re: [Tagging] war_memorial

2017-10-03 Thread Janko Mihelić
uto, 3. lis 2017. u 12:19 Martin Koppenhoefer 
napisao je:

>
> There also a "topic" key in small use:
> https://taginfo.openstreetmap.org/keys/topic#values maybe rather than
> theme it could be "memorial:topic=war"?
>
>
Ok, memorial:topic=war.

Is this thread enough to deprecate war_memorial on the wiki? Or should we
first create a new wiki for memorial:topic=*?

I would also bring up the tag subject:wikidata=*, but I'm afraid the
current flames on other threads would spread here :)

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


Re: [Tagging] war_memorial

2017-10-03 Thread Janko Mihelić
I propose we deprecate memorial=war_memorial. It's in conflict with other
values of this key. We can use memorial:theme=war_memorial. We can expand
this with other values, like memorial:theme=notable_person, notable_event,
and so on.

Janko

uto, 3. lis 2017. u 11:15 demon.box  napisao je:

> hi, I would tag a war memorial for example like these:
>
> <
> http://gis.19327.n8.nabble.com/file/t339261/Monumento_ai_caduti_a_Gela.jpg
> >
>
> <
> http://gis.19327.n8.nabble.com/file/t339261/targa_caduti_piazza_martiri2.jpg
> >
>
> so I choose:
>
> historic=memorial
> memorial=war_memorial
>
> but how can I specify the kind of it (stele, plaque, ecc.)?
>
> thanks very much.
>
> --enrico
>
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> 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] Mapping hotels on buildings or areas around buildings

2017-09-29 Thread Janko Mihelić
On Sat, 30 Sep 2017, 01:46 Neil Matthews  wrote:

> I guess keep the name/address on the main building/reception or on an
> entrance node -- adding it to the landuse (grounds) will just "weaken"
> routing (may make the  rendering confusing too)?
>
> I think it would be good to see a few diagrams -- and a thought where
> "name" and "addr:" tags should ideally go too?
> And maybe a hint for renderers too :-)
>

Also, where do swimming_pool=yes and sauna=yes go? To the whole
tourism=hotel area, or the building=hotel. Or both?

Janko

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


Re: [Tagging] Mapping hotels on buildings or areas around buildings

2017-09-29 Thread Janko Mihelić
On Fri, 29 Sep 2017, 20:42 Kevin Kenny  wrote:

> On Fri, Sep 29, 2017 at 1:16 PM, Mark Wagner 
> wrote:
>
> A renderer - any conceivable renderer, not just the default renderer -
> to do a good job needs to decide "is this area a building, or is it
> not?"
>

An item is a building only if it has a tag building={anything other than
no}. It's pretty simple.

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


[Tagging] Mapping hotels on buildings or areas around buildings

2017-09-29 Thread Janko Mihelić
Hi,

should only the hotel buildings be tagged with tourism=hotel or the whole
area that is owned by the hotel?

I think if the hotel doesn't have more than one building, and if the hotel
grounds are not very big, or if they are accessible by public, only the
building gets tagged. But if there are more buildings, outside pool and/or
parks accesible only by guests, we might consider tagging an area around
those buildings.

Does this thinking align with most mappers?

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


Re: [Tagging] Elevation in Feet as part of Peak Names

2017-09-08 Thread Janko Mihelić
Elevation doesn't go in "name" tag, that's quite obvious. But I think
elevations in feet shouldn't be discouraged. Maybe sometimes you have
iconic elevations of mountains in feet everybody knows and learns in
school, and they want to see that number exactly on a map, and not some
fraction after converting from meters, like, Denali is 20155.9894568543 ft
high.

Janko

pet, 8. ruj 2017. u 10:57 Lukas Sommer  napisao je:

> The wiki page for https://wiki.openstreetmap.org/wiki/Key:ele says it
> has to be in meters, not in feets.
>
> --
> Lukas Sommer
>
> ___
> 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] service=access

2017-08-11 Thread Janko Mihelić
I'm struggling to think of another use for any highway besides access.
Maybe a scenic highway whose use is to look at surroundings while driving.

I suggest service=pipeline_access.

ned, 6. kol 2017. u 18:58 Dave Swarthout  napisao
je:

> You're probably right Gerd. I sometimes get too enthusiastic about adding
> tags to objects. The access tag is probably completely unnecessary. Still,
> I'm curious about why other mappers decided to use it.
>
>
>
> On Sat, Aug 5, 2017 at 8:49 PM, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Dave,
>>
>> my understanding is that most hw=service are used to access a specific
>> man_made object, so this tag
>> seems to be superfluous to me. I would simply not use the service tag
>> here.
>>
>> Gerd
>> 
>> Von: Dave Swarthout 
>> Gesendet: Samstag, 5. August 2017 23:02:18
>> An: Tag discussion, strategy and related tools
>> Betreff: [Tagging] service=access
>>
>> Hi,
>>
>> I'm working on highway tagging in Alaska and am developing a preset to
>> automate the tagging of the many gravel service roads that are used to
>> access the Trans-Alaska Pipeline (TAP). I have never used the
>> service=access tag and there is nothing in the Wiki about it but it would
>> seem to be an ideal tag to use in my work because those roads are being
>> used to get close to the TAP, in other words, to access it. Taginfo shows
>> about 600 uses of the tag and most of those appear to be for unpaved
>> service roads similar to the ones I'm seeing in my work.
>>
>> However, seeing as no documentation of the tag exists, I'm wondering if
>> any of you have used this tag or have some insights to offer.
>>
>> As always, thanks in advance.
>>
>> Dave
>>
>>
>>
>> --
>> Dave Swarthout
>> Homer, Alaska
>> Chiang Mai, Thailand
>> Travel Blog at http://dswarthout.blogspot.com
>>
>
>
>
> --
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rivers classification

2017-08-08 Thread Janko Mihelić
pon, 7. kol 2017. u 21:48 Daniel Koć  napisao je:

> We could also try to craft internal classification similar to mix used
> with roads, for example:
>
> "big river - "medium river - "small river -
>
>
I agree with this, but we should also correlate these tags with some
objective attributes like CEMT if available. Countries love their own
features, so the biggest river in a country will always get the "big river"
tag, however small it is. Luckily, big rivers are often international so
that should correct things a bit.

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


Re: [Tagging] Rivers classification

2017-08-06 Thread Janko Mihelić
(Wrong title sorry, here it is again)


There is the CEMT tag, but I guess it's only useful for Europe:



http://wiki.openstreetmap.org/wiki/Key:CEMT



Janko

ned, 6. kol 2017. u 13:34 Richard  napisao je:

> On Sun, Aug 06, 2017 at 11:26:23AM +0200, Daniel Koć wrote:
> > I was thinking about better rendering rivers on medium and low zoom
> levels
> > of osm-carto and I've found that we lack any classification of them -
> > anything bigger than stream is just a river.
>
> as of rendering, respecting river width and doing something reasonable
> with intermittent flows would be a great progress.
> Iirc the stream order issue has been brought up on some talk page
> previously.
>
> Also had a look at natural=riverbed which at this stage has some
> problems.
>
> 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


[Tagging] Odg: Rivers classification

2017-08-06 Thread Janko Mihelić
There is the CEMT tag, but I guess it's only usefull for Europe:

http://wiki.openstreetmap.org/wiki/Key:CEMT

Janko

Pošiljatelj: Daniel Koć
Poslano:6. kolovoza 2017. 11:28
Primatelj: Tagging@openstreetmap.org
Predmet: [Tagging] Rivers classification

I was thinking about better rendering rivers on medium and low zoom 
levels of osm-carto and I've found that we lack any classification of 
them - anything bigger than stream is just a river.

There are no suitable tags defined:

https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver

and no such tags in database too:

https://taginfo.openstreetmap.org/tags/waterway=river#combinations

There are some waterway classification systems used in cartography:

https://en.wikipedia.org/wiki/Stream_order#Usage

but how should we tag them?

-- 
"Like a halo in reverse" [M. Gore]


___
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] man_made=tunnel

2017-06-14 Thread Janko Mihelić
sri, 14. lip 2017. u 17:02 Martin Koppenhoefer 
napisao je:

>
> what do you mean with "both"? Is this "all with the same name"? I agree
> with this, tunnels often come as sets of tubes. How would we deal with
> cases with several tubes, where the individual tubes have individual names?
> Is the idea to draw an area (or multipoligon) for the tube/s? Or should
> this be some kind of relation (with the ways in the tunnel as members)?
>

Now that I think of it, I wouldn't be opposed to mapping tunnels as ways in
a relation. Take all road ways that are in the tunnel, and put them in a
tunnel relation. It's easy, and you can't see the tunnel outlines on a
satellite image anyway. In that case multipolygon relation doesn't make
sense. A proposal for this already exists:
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels
And there are 435 tunnels tagged like this. As opposed to 172 tunnels
tagged with man_made=tunnel.


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


Re: [Tagging] man_made=tunnel

2017-06-14 Thread Janko Mihelić
uto, 13. lip 2017. u 17:10 Eugene Alvin Villar  napisao
je:

> On Mon, Jun 12, 2017 at 11:30 PM, Philip Barnes 
> wrote:
>
>> I would map those as separate tunnels and only map them as a single
>> tunnel is multiple ways share the same bore.
>>
>
> I think this goes to the question of whether we want man_made=tunnel to
> map a physical tunnel (that may contain a dual carriageway) or a tunnel
> system (that is given just a single name).
>

I think we should keep it simple for this tag (man_made=tunnel) and map
both bores with one element. We can add attributes like bores=2. Then if we
want to go deeper, invent new tags (tunnel:part=main_bore,
tunnel:part=connect_bore).

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


Re: [Tagging] man_made=tunnel

2017-06-12 Thread Janko Mihelić
pon, 12. lip 2017. u 10:58 Martin Koppenhoefer 
napisao je:

> A question might be in some cases whether they are one tunnel with distant
> tubes, or 2 tunnels "which happen to have the same name", because unlike
> the carriageways on a bridge, every tunnel tube is a distinct structure,
> and sometimes different directions can be quite far away and have different
> shape (i.e. they are not parallel).
>

But they often have little connecting tunnels for emergencies and
servicing, so in a way, you can say it's the same tunnel. The problem is,
its hard to map underground connecting tunnels.

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


Re: [Tagging] how to tag small parts of buildings

2017-04-17 Thread Janko Mihelić
I like inscription=* for inscriptions. Maybe add a historic=inscription as
well.
I'm not sure about the other ones. How will they be used by data consumers?
Wouldn't a photo on OpenStreetCam be a better option?

Janko

On Fri, 14 Apr 2017, 00:38 Martin Koppenhoefer, 
wrote:

> While mapping a medieval village I have found some features I would like
> to map but am not aware of established tags for them.
>
> These features are generally parts of building facades, for example
>
> - inscriptions, often initials of former proprietors or restoration dates.
> Sometimes these are engraved in stone frames of doors, or they are engraved
> into stones that are inserted into the facade
> - particular (original historic) architectonic elements, e.g. a mullioned
> window in a house
> - other stone parts in the facade (spoils), e.g. consoles, sculptural
> artwork (e.g. statues holding architectonic elements like oriels, etc.)
>
>
> as these are parts of the facade and I would like to store their position
> as well, I don't want to add them as properties to the buildings
> themselves. Rather they could be ways or nodes, according to their size.
>
>
> I am interested to learn if someone has already mapped something similar
> and with which tags, or what you think would be a good representation.
>
>
> Should I invent a new key facade:part=* ?
> Or better use the historic key?
>
> Cheers,
> Martin
>
> sent from a phone
> ___
> 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] Starbucks or Starbucks Coffee

2017-03-21 Thread Janko Mihelić
Just put "brand:wikidata=Q37158" and you're done with it. Names are not
universal identifiers. Making machine edits to rename hundreds of stores
doesn't help all that much, and can create edit wars.

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


Re: [Tagging] address property of features

2017-03-18 Thread Janko Mihelić
Imagine a data consumer trying to find out the address of all those stores.
Not only is it hard because you have to find surrounding areas and extract
the address, but in your case it's impossible because you can't know for
sure which entrance it took its address from. What's your solution to that?
The only solution I see is relations, but IMHO that would be a mess.

Janko

On Sat, 18 Mar 2017, 17:57 Tristan Anderson, 
wrote:

> I"m not sure I agree.
>
>
> Let's say a store has three entrances: 2, 4 and 6 Main Street.  The store
> uses it's main entrance, 4 Main Street, as it's address.  Are you
> suggesting using the addr:housenumber key four times: a node at each
> entrance in addition to a tag on the store?  Now you've tagged 4 Main
> Street twice, even though there is only one 4 Main Street.  Either tag the
> store or the entrance, not both.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Vertical farming

2017-03-18 Thread Janko Mihelić
Can you show us a photo of the typical building? If it was a warehouse
turned into a farm, then building=warehouse. If it is a building
specifically made for vertical farming, then building=vertical_farm.

Janko

On Sat, 18 Mar 2017, 03:07 Dave Swarthout,  wrote:


@Martin, I fully realize "commercial" buildings have many variations and
styles, as your link points out. I chose building=commercial (535K uses)
because it's a category that encompasses all of those variations yet is
more specific than merely building=yes (838 million uses) . Can you suggest
something better?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] address property of features

2017-03-18 Thread Janko Mihelić
I agree. Duplicating addresses on features is not a problem, but a feature.

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


Re: [Tagging] Is there a way to make tags better?

2017-03-16 Thread Janko Mihelić
What about using an existing solution, Wikibase[1] (of which Wikidata is an
example)? Let's call it OSMdata. Wikibase is great because it allows for
all kinds of structured data, which makes it future-proof. Some examples of
use would be:

We could add links to outside databases, for example Wikidata, or some
other structured source that would add semantic meaning to some specialized
tags. So if there is an unique ID of a special type of buoy, connect it to
our seamark:type=cardinal_buoy tag on OSMdata.

Create items that are tag combinations, and give those combinations
additional data. For example, create an OSMdata item for
amenity=place_of_worship+religion=buddhist, link it with the Wikipedia
article about Buddhist temples. This gives more info about tag
combinations, and in some way formalizes those combinations.

Translations to all possible tag combinations (usable by all editors, and
Nominatim for example)

Add additional "meta tags", depending on the region they are found in. For
example, default max_speed on highway=motorway in Spain.

Create items for big geographical entities, like continents and oceans, and
then, instead of relations, tag boundaries of those objects with the
OSMdata ID.

And countless other examples...

[1] https://www.mediawiki.org/wiki/Wikibase

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


Re: [Tagging] memorial:type and memorial

2017-01-16 Thread Janko Mihelić
There was a similar topic about memorials and artworks a while ago, and I
mentioned my idea of a tag like sculpture_shape. It would have values like
bust, person_standing, person_sitting, person_on_horse, abstract and so on.
Then there's already a well established tag subject:wikidata=Qxxx. With
those two tags we have the way it looks (if it's a sculpture), and who/what
it's dedicated to.

If a memorial is about a specific battle, data consumers would still like
to know that it is a war_memorial. So subject:wikidata=* (or subject=*)
should point to the specific battle, but some other tag should explain the
broader subject. Maybe topic=* or theme=* with values like battle,
mass_killing, war_hero, notable_person_death, notable_person_home,
notable_event, archeological_finding ...

memorial=stolperstein is fine by me because it describes the shape and the
topic in one tag.
Also memorial:type=plaque, plate, stele, obelisk seem ok to me.

Janko

pon, 16. sij 2017. u 10:06 Martin Koppenhoefer 
napisao je:

> What is the "type" or "kind" of a memorial?
> There are currently different ideas crammed together in the subkeys, some
> referring to the physical appearance, others referring to the topic or
> scope/reason.
>
> E.g. the suggested/documented tags:
> memorial:type/memorial=plaque
> memorial:type/memorial=plate
> memorial:type/memorial=statue
> memorial=bust
> memorial:type/memorial=stele
> memorial=stone
> memorial:type/memorial=obelisk
>
> all refer to the physical aspect of the memorial.
>
> The suggested tag:
> memorial=war_memorial refers to the topic of the memorial
>
> the suggested tags
> memorial:type/memorial=stolperstein
> memorial=blue_plaque
> because they are very specific, refer to both, the physical aspect and the
> topic/scope.
>
> IMHO we should have distinct tags for these properties, because they occur
> indepently/are different properties.
>
> 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] Proper way to tag highways located in "dangerous" areas

2016-11-20 Thread Janko Mihelić
That means it's flawed, not subjective. So give it a few sources, and they
will more or less cancel each others flaws.

Recording crime rate is not an exact science, so of course it can never be
perfect. But perfect is the enemy of good enough.

Janko

sub, 19. stu 2016. u 12:53 Paul Johnson <ba...@ursamundi.org> napisao je:

On Thu, Nov 17, 2016 at 2:15 PM, Janko Mihelić <jan...@gmail.com> wrote:

On Thu, 17 Nov 2016, 20:44 Paul Johnson, <ba...@ursamundi.org> wrote:


Don't.  Too subjective, and tends to highlight some kinds of bigotry while
basically giving a pass to other kinds.


How is it subjective if you take data from the local police?


Very.  Portland Police, for example, have a policy of not taking reports if
nobody gets sent to the hospital or the crime isn't a felony in an effort
to keep the city's crime stats artificially low.
___
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] Proper way to tag highways located in "dangerous" areas

2016-11-17 Thread Janko Mihelić
On Thu, 17 Nov 2016, 20:44 Paul Johnson,  wrote:

>
> Don't.  Too subjective, and tends to highlight some kinds of bigotry while
> basically giving a pass to other kinds.
>

How is it subjective if you take data from the local police?

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


Re: [Tagging] Proper way to tag highways located in "dangerous" areas

2016-11-16 Thread Janko Mihelić
I think if a tag is used for this, it should be clear what the source is.
For example, if you have police info about which streets are dangerous,
then put a tag like:

hazard:source:policeStationXY=crime.

If you have a NGO that tracks this, put

hazard:source:NGOXY=crime.

That way you could have two hazard tags, each from it's own source. And
then routers can choose what source they can listen to, and it can also be
verified. If there was no verification, someone could put that tag on their
own street to reduce traffic.

Janko

sri, 16. stu 2016. u 12:11 joost schouppe 
napisao je:

> Absolutely agree that access=destination is wrong here.
>
> I also like the idea of using an external dataset. Actually, the
> similarity with an altitude model is quite interesting. You could use an
> existing router that takes elevation data and replace it with crime data.
> Converting crime statistics to something that looks like an altitude model
> is straightforward with a GIS tool. Or someone could make a website
> (probably exist already) to collect opinions on security by neighborhood,
> then convert to an altitude model. Crime being quite concentrated (in my
> city 80% of all registered violent crime is concentrated in just 16% of the
> city), a router wouldn't have much trouble avoiding the higher places.
>
> 2016-11-16 11:36 GMT+01:00 Rory McCann :
>
> I don't think tagging access=destination is a good idea. The access tag
> is used for the legal restrictions for a road. access=destination means
> you can only legally go on the road if your destination is on it. A
> router won't route you down a road that it thinks you (legally) can't go
> down. Tagging that way will stop the router routing you on it, but for
> the wrong reason. You're "tagging for the router".
>
> Many countries use access=destination to mean this, I suppose the
> Brazilian community could use the tag in a different way, but it'd
> usually better for us all to use the same tag/values. 
>
> There are some possible solutions to your problem:
>
> Are slums/flavelas (sp?) tagged/mapped in OSM? If so, a router may be
> able to downgrade roads that are near a slum by looking at what's nearby.
>
> Do the roads in slums have any common physical properties? Like always
> being narrow, with no footpaths, lower speed limits, etc? You could map
> those attributes, and a router might be able take them into account. (A
> narrow road with pedestrians walking on it, and a low speed limit might
> be downgraded compared to a more straighter, easier-to-drive road).
>
> The idea of using an external dataset to inform routing isn't new. Some
> bicycle routers use external elevation data to not route people up and
> then down a hill. Perhaps there's a dataset of crime/damgerous areas you
> could combine with OSM data to make a better router.
>
> However I don't know if any/many routers currently support this kind of
> features. So people might just want to keep using the routers they have
> and "fix" them.
>
>
> On 16/11/16 02:04, Nelson A. de Oliveira wrote:
> > It's the second time that we are having a major discussion here in
> > Brazil, on how to tag highways located in "dangerous" areas.
> > For example, some people consider slums and other communities as
> > dangerous (since there is a risk of being robbed or even killed) and
> > would like to don't have the router creating a route through them,
> > using "access=destination" in every street located in such places for
> > this, for example.
> >
> > Since they can't find another tag to indicate those "dangerous"
> > places, they argue that access=destination is valid for this case.
> >
> > Other group (including me) find that this is wrong: we should not tag
> > streets considered dangerous in OSM (specially when "dangerous" is
> > subjective).
> > We also think that access=destination is being wrongly used for this.
> >
> > Since we can't reach a consensus on this, we would like to hear some
> > opinions and suggestions on how to handle such problem, please.
> >
> > I had one idea where such data should be kept outside OSM, and
> > inserted in some post-processing phase (for example, tag every highway
> > that is inside these areas with any needed/wanted property).
> >
> > Comments, please?
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>
> --
> Joost @
> Openstreetmap  |
> Twitter  | LinkedIn
>  | Meetup
> 
> ___
> Tagging mailing list
> 

Re: [Tagging] Proper Tag for Not-a-Roundabout

2016-11-07 Thread Janko Mihelić
Here is an example of a not-a-roundabout without lights:

https://goo.gl/maps/TVuMRZs59Kk

It even has a roundabout sign, but the right of way is clear through signs
on the ground.

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


Re: [Tagging] Busways

2016-11-02 Thread Janko Mihelić
I look at service highways as most general highways. All highways are
service highways, but residential highways are a special type, motorways
are another special type and so on. So anything that is a highway but is
none of these special types, then it's a service.

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


Re: [Tagging] health_facility:type vs. health_facility_type

2016-09-29 Thread Janko Mihelić
She did it manually, it's described in the next diary entry:

http://www.openstreetmap.org/user/jinalfoflia/diary/37655

I see now that group messaging is a planned feature, so all we have is
manual for now.

Janko

On Thu, 29 Sep 2016, 13:04 Janko Mihelić, <jan...@gmail.com> wrote:

> I got a message like that, and it was about a mechanical edit described
> here:
>
> http://www.openstreetmap.org/user/jinalfoflia/diary/37601
>
> but it says nothing about the messages. I got a message "after" the
> mechanical edit was done, which is maybe a bit controversial, but that's ok
> if you ask me. It was an obvious error (amenity=picnic_site instead of
> tourism=picnic_site). I asked the user jinalfoflia if she can tell me how
> she sent all those messages, and I'll report back if I get an answer.
>
> Janko
>
> čet, 29. ruj 2016. u 11:40 Jean-Marc Liotier <j...@liotier.org> napisao je:
>
>> On 2016-09-28 13:56, Janko Mihelić wrote:
>>
>> Maybe send an automatic message to those 66 users to see if they agree
>> with the edit, and if most agree, change them all
>>
>> Good idea... I don't know how to send a message to such a group of users
>> - is there functionality provided for that ?
>>
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Piste:type=connection

2016-09-29 Thread Janko Mihelić
I agree ski tagging needs something like this. I have some
questions/suggestions:
1. Who is to be routed through these connections? Only downhill skiers, or
nordic skiers, sleigh riders, snowmobiles also? I think we could route all
snow transport over it.
2. Are they implicitly oneway? They are two way more often than not, but I
think we should stick to them being oneway, just to match the
piste:type=downhill. If they are not oneway, add oneway=no.
3. Do we call those forest tracks that connect two mountains
piste:type=connection? They exist only for connecting pistes, but I'm not
sure if you wanted to include those in piste:type=connection. Additionally,
those are not necessarily meant for all types of snow transport. Or maybe
they are, I don't know. They are all pretty easy to ride on, so maybe even
nordic skiers could be routed through them.

Janko


uto, 27. ruj 2016. u 12:57 Helge Fahrnberger  napisao
je:

>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Piste:type%3Dconnection
>
> Ways that connect ski lifts with each other, mainly for routing purposes
> ___
> 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] health_facility:type vs. health_facility_type

2016-09-29 Thread Janko Mihelić
I got a message like that, and it was about a mechanical edit described
here:

http://www.openstreetmap.org/user/jinalfoflia/diary/37601

but it says nothing about the messages. I got a message "after" the
mechanical edit was done, which is maybe a bit controversial, but that's ok
if you ask me. It was an obvious error (amenity=picnic_site instead of
tourism=picnic_site). I asked the user jinalfoflia if she can tell me how
she sent all those messages, and I'll report back if I get an answer.

Janko

čet, 29. ruj 2016. u 11:40 Jean-Marc Liotier <j...@liotier.org> napisao je:

> On 2016-09-28 13:56, Janko Mihelić wrote:
>
> Maybe send an automatic message to those 66 users to see if they agree
> with the edit, and if most agree, change them all
>
> Good idea... I don't know how to send a message to such a group of users -
> is there functionality provided for that ?
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


  1   2   3   4   5   >