Re: [Tagging] Difference between graffiti and mural

I think anything two dimensional on a wall and with the purpose of creating an art piece is a mural. We can add a new tag like art_technique=scratching, cleaning, spray_paint, etc.. There is a fuzzy border into graffiti, where the purpose is for little rebels without a cause to have their tags be

[Tagging] Feature Proposal - RFC - healthcare=department

Mappers, I'm proposing https://wiki.openstreetmap.org/wiki/Proposed_features/healthcare%3Ddepartment A tag for mapping departments of hospitals or clinics. We can discuss it here on the mailing list, but there is already an active discussion on the community web site:

[Tagging] Literal translation of street names

eate a new tag, name:literal_translation:en=* or just literal_translation:en=*. Another question, what is the right name:en=* in these cases, or is there none? Erinnerung Road? Thanks! Janko Mihelić ___ Tagging mailing list Tagging@openstreetmap

Re: [Tagging] Feature Proposal - RFC - highway=scramble

čet, 15. ruj 2022. 19:57 Peter Elderson je napisao: > I know, but the scale does not indicate specific things you encounter, > just that somewhere along the way you will be challenged. > That isn't true. If you tag a relation with sac_scale, then it is as you say. But if you tag a way with

Re: [Tagging] Feature Proposal - RFC - highway=scramble

čet, 15. ruj 2022. u 14:52 Peter Elderson napisao je: > Which combination(s) of highway values, sac scale values and hazard values > would exclusively represent a scramble (Dutch verb: klauteren, i.e. going > up or down there using hands and feet) to a grown-up, non-challenged, > average hiker

Re: [Tagging] Feature Proposal - RFC - highway=scramble

This is a bit similar to highway=via_ferrata which is a pretty heavily used tag (2701 objects). https://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata Via ferrata needs to have infrastructure like rungs, ladders, bridges and similar. I guess scramble would be similar, but without

Re: [Tagging] Fuzzy areas again: should we have them or not?

The fifth alternative is move the big areas to an outside repository: https://github.com/dieterdreist/OpenGeographyRegions This might be a great alternative until we find a better solution. And there might not be a better solution. Janko pon, 21. pro 2020. u 10:22 Anders Torger napisao je: >

Re: [Tagging] edit war related to tagging of a bus-only major road

I think "service" is more appropriate than highway=secondary. Highway=service has in my opinion a wider scope than secondary. In a way, secondary is a special type of highway=service (that's the way I look at it, though other mappers probably don't look at it that way). So if a road can not be

Re: [Tagging] Feature Proposal Rejected - RFC - Admission

I agree, "issue" is a bit vague. Does "issuer" sound better? https://en.m.wiktionary.org/wiki/issuer#English Usually I'm not the one to nitpick, but I don't want to lose the scenario where the tickets are free. Also, distributer doesn't sound like it would describe small scenarios, like when you

Re: [Tagging] Feature Proposal Rejected - RFC - Admission

I fixed the wiki of the proposal, any new comments before I start the voting again? https://wiki.openstreetmap.org/wiki/Proposed_features/Admission Janko čet, 26. stu 2020. u 16:43 Janko Mihelić napisao je: > Results: 1 approved, 6 opposed, 3 abstained. > > https://wiki.openstreetmap

[Tagging] Feature Proposal Rejected - RFC - Admission

Results: 1 approved, 6 opposed, 3 abstained. https://wiki.openstreetmap.org/wiki/Proposed_features/Admission No one was opposed to the core idea of the Admission proposal, just technicalities. So we should go over them and later try again: 1. access=admisson This was the biggest problem, five

Re: [Tagging] Deprecate water=pond?

I think the question here isn't if pond makes sense for data consumers. Mappers are what matters in this case. If there is a little 4 meter pond, mappers will not tag it as a lake because it sounds wrong. So they will probably tag it just natural=water. But then we lose information about if it is

[Tagging] Feature Proposal - Voting - Admission relations

I started the voting process on the Admission proposal. Admission is a potential new concept in OpenStreetMap, and it might get updated in the future, but I think this is a good first step. Thanks for taking the time to vote and comment!

Re: [Tagging] Proposal for admission=* tag

Okay, it took a while, but I revised the wiki of the proposal. I removed the possibility of tagging without relations, and added a table with examples of tagging. https://wiki.openstreetmap.org/wiki/Proposed_features/Admission#Additional_relation_tags Send your opinions. uto, 27. lis 2020. u

Re: [Tagging] Proposal for admission=* tag

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

Re: [Tagging] Proposal for admission=* tag

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 admis

Re: [Tagging] Proposal for admission=* tag

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? >

Re: [Tagging] Proposal for admission=* tag

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

Re: [Tagging] Proposal for admission=* tag

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

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

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

[Tagging] Proposal for admission=* tag

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

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

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

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.

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

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

Re: [Tagging] Best practices regarding implied tags

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.

Re: [Tagging] Best practices regarding implied tags

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Tagging] Adding mapillary tags to every building

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 >

Re: [Tagging] Adding mapillary tags to every building

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.

Re: [Tagging] Adding mapillary tags to every building

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

Re: [Tagging] Adding mapillary tags to every building

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

[Tagging] Adding mapillary tags to every building

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

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

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

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

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

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,

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

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

Re: [Tagging] Real time in public transport

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. > >

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

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

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

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

Re: [Tagging] mesh bicycle network

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

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

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

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

č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

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

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

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

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

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

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 ... >

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

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

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

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

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

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

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

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

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

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

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

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

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

( 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 s

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

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

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

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: &

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

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:wik

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

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,

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

ndreds 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

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

Re: [Tagging] Mistagging footways as highway=pedestrian

č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

Re: [Tagging] Mistagging footways as highway=pedestrian

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,

Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

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

Re: [Tagging] historic=memorial tagging question

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 h

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

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

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

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

Re: [Tagging] 3d-tagging

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

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

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

Re: [Tagging] Public art definition

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 >

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

. 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 nob

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

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

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

Re: [Tagging] Difference between lighthouses and beacons

č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

Re: [Tagging] Difference between lighthouses and beacons

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

[Tagging] Difference between lighthouses and beacons

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

Re: [Tagging] Questions on building-tag

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

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

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

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

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

Re: [Tagging] airstrip vs runway

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

Re: [Tagging] war_memorial

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. >

Re: [Tagging] war_memorial

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

Re: [Tagging] war_memorial

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

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

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

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

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

[Tagging] Mapping hotels on buildings or areas around buildings

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

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

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

Re: [Tagging] service=access

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

Re: [Tagging] Rivers classification

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

Re: [Tagging] Rivers classification

(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

[Tagging] Odg: Rivers classification

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

Re: [Tagging] man_made=tunnel

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

Re: [Tagging] man_made=tunnel

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

Re: [Tagging] man_made=tunnel

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

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

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:

Re: [Tagging] Starbucks or Starbucks Coffee

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

Re: [Tagging] address property of features

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

  1   2   3   4   5   >