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.

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

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.

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

[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

[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

[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

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

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

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

[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

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 >

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.

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

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

[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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2019-09-09 Thread Janko Mihelić
( 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

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

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

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

2019-09-06 Thread Janko Mihelić
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?

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,

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

2019-08-02 Thread Janko Mihelić
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

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

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

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,

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

Re: [Tagging] historic=memorial tagging question

2018-10-18 Thread Janko Mihelić
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

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

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

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

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

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 >

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

2018-01-23 Thread Janko Mihelić
. 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

2018-01-23 Thread Janko Mihelić
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

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

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

[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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

[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

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

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

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

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:

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

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

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:

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

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

2016-11-20 Thread Janko Mihelić
;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

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

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

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

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

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

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

Re: [Tagging] health_facility:type vs. health_facility_type

2016-09-29 Thread Janko Mihelić
> 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 -

Re: [Tagging] health_facility:type vs. health_facility_type

2016-09-28 Thread Janko Mihelić
Maybe send an automatic message to those 66 users to see if they agree with the edit, and if most agree, change them all. Janko On Tue, 27 Sep 2016, 19:46 Jean-Marc Liotier, wrote: > health_facility:type : 7752 occurrences, mentioned in the Healthcare 2.0 > proposal,

Re: [Tagging] Cenotaph WAS Re: Tagging memorial sites

2016-09-21 Thread Janko Mihelić
sri, 21. ruj 2016. 02:59 Martin Koppenhoefer je napisao: > > You can (also additionally) add a memorial:type=cenotaph. > Memorial:type is a bad tag. Look at the values: https://taginfo.openstreetmap.org/keys/memorial%3Atype#values There's obelisk, and then there is

[Tagging] Tagging memorial sites

2016-09-19 Thread Janko Mihelić
There's a lot of memorials that commemorate battles, mass killings, an idea, or some other notable thing. Sometimes it's a plaque or a statue, but sometimes it's a huge site. Examples are: Battle of Mohács memorial: https://en.wikipedia.org/wiki/File:Mohacs_Monument_at_the_Battlefield_2004.JPG

Re: [Tagging] Playgrounds/Play zones in forests

2016-09-10 Thread Janko Mihelić
Maybe just add playground_type=forest_playground, nature_playground or something like that. Janko Dana 10. ruj 2016. 16:43 osoba "Marc Gemis" napisala je: > I encounter more and more playground ("play zones") in forests. These > are areas were children can use the natural

Re: [Tagging] cave_entrance. ref and name

2016-09-07 Thread Janko Mihelić
I would add in the wiki that if the tag cave:name=* is absent, name=* can be considered to be the name of the cave and the entrance. That way we are consistent with the way the name tag was used until now. Janko sri, 7. ruj 2016. u 12:25 Martin Koppenhoefer napisao je:

Re: [Tagging] cave_entrance. ref and name

2016-09-06 Thread Janko Mihelić
What about renderers? Should they render name or cave:name? If a small cave has only one entrance, is it right to name that entrance by the name of the cave? It's probably going to be used that way. We should tell Nominatim to start indexing cave:name tags. Janko uto, 6. ruj 2016. u 09:47

Re: [Tagging] artificial cave, historic military shelter

2016-09-02 Thread Janko Mihelić
I'm not sure. Natural=cave is for natural caves, but the wiki on the cave page says that man made caves are historic=mine: http://wiki.openstreetmap.org/wiki/Cave#Man_Made Historic=mine wiki talks only about mineral mines. Shelter_type=rock_shelter is also a natural rock formation, not deep

Re: [Tagging] [OSM-talk] Artwork problems

2016-09-01 Thread Janko Mihelić
pet, 2. ruj 2016. u 00:36 Daniel Koć napisao je: > There are 3 equivalents of a common case (memorial in the form of > statue): > - historic=memorial + memorial:type=statue > - historic=memorial + memorial=statue > - historic=memorial + tourism=artwork + artwork_type=statue > >

  1   2   3   4   5   >