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

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 meters

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 th

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

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

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

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 real

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 al

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

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

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

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 utility=communica

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

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

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

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

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 matc

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 i

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 shou

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

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

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

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

[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! https://wiki.openstreetmap.org/wiki/Proposed_features/Admiss

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 a

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

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

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 g

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 clas

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

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 those

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 wi

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 sac_s

[Tagging] Literal translation of street names

o deal with this is to create 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 l

[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: https://community.openstre

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 s

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

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_fe

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

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

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 r

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 wron

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

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 alway

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 ite

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 shou

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

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

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

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 h

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

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

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] Roman roads - was Re: "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

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 b

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

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

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

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 isn

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

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 probl

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 2019

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

th 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] 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, wa

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

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] Proposed features - Voting - Pressurized waterways

line, 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, b

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 > ___ Tagging mailing li

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 values are: 1. canal - big e

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 an

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 wh

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 answers

Re: [Tagging] historic=memorial tagging question

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

Re: [Tagging] How to overcome lack of consensus

2013/9/18 Martin Koppenhoefer > > I think it is a bad idea to connect the meaning of osm tags to definitions > in wikipedia, because the content of wikipedia articles is not something we > control. When the wikipedia article changes (e.g. it gets extended or > restrained by splitting it up) it do

Re: [Tagging] How to overcome lack of consensus

2013/9/19 Martin Koppenhoefer > is it? > I don't know, and nobody does because we don't have an ontology. If someone asks me, then yes, fastfood is a restaurant. If someone asks you, than a restaurant means "slow food". If we decide it's "slow food" we don't put them one over the other. If we d

Re: [Tagging] How to overcome lack of consensus

2013/9/19 Martin Koppenhoefer > > but it will always result in flattening complexity (and therefor detail > and small but fine distinctions). > On the contrary, I have a feeling this would increase complexity. Right now, if you invent a new tag, for example "amenity=slow_food_restaurant", ther

Re: [Tagging] proposal: intersection with equal roads

Hi, I like it, but I would use something other than "highway" for a key. Maye "junction"? Janko 2013/9/23 Balázs Barcsik > Hi There! > > Please have a look on this new proposal: > http://wiki.openstreetmap.org/wiki/Intersection_with_equal_roads > Thanks in advance! > > Balazs > > > On Sun, S

Re: [Tagging] proposal: intersection with equal roads

2013/9/24 fly > > I am not sure about this tag. I understand the intension but in Germany > this is the default situation for all intersection if not marked > different and I would prefer to not tag the default. E.g. get all > traffic_signal, stop and give_way mapped and the rest would be "right

Re: [Tagging] waterfall

Maybe waterway=waterfall could be a node on the way (or a a way, if waterfalls are long), and natural=waterfall could be an area showing where they are. A similar difference to waterway=river and waterway=riverbank. Janko 2013/9/25 Martin Koppenhoefer > > 2013/9/25 Volker Schmidt > >> You ove

Re: [Tagging] mapping qanats

Wow, I never heard of qanats. man_made=qanat and qanat=shaft sound ok, although I would rather use waterway=qanat. I see there are only 3 man_made=qanats mapped right now, so there is no problems with changing those. Janko 2013/9/27 Michał Sałaban > Hi, > > I've just created a proposal page

Re: [Tagging] mapping qanats

I think this is quite a unique structure that can't be described with "canal". Especially if the main reason is rendering. Canals are not used for drinking water, the concept is entirely different. If I had to use anything, I would use aqueduct , but I w

Re: [Tagging] mapping qanats

On the canal wiki article it says "An artificial open waterway used for transportation, waterpower, or irrigation." I guess we have to add "drinking water" to that list. When you look at the Wikipedia canal article, the

Re: [Tagging] mapping qanats

2013/9/28 Michał Sałaban > > I realized it is not easy to make a distinction between canal and > aqueduct, but we may assume that the latter is usually for drinking > water or irrigation of small areas of land. Everything dealing with > navigation, flood protection or vast area irrigation would b

Re: [Tagging] Which map supports complete bridge rendering

I have a feeling f4-group[1] will be the first one to render this data. They have a great 3D map already, and have added SRTM data recently. Bridges could be problematic though, because they interact with the surrounding terrain. OSM2World[2] is also a project that is quite promising. [1] http://

Re: [Tagging] Ferry frequency

I have been talking about this on the transit mailing list[1]. I formed a tag that gives us a number of journeys in any given period. It is very flexible, and can be simple and complex. For example, if we want to say there are 3 journeys a day, we would simply have: public_transport:frequency=d3

Re: [Tagging] Ferry frequency

2013/10/4 Richard Fairhurst > To clarify, I'm not looking to put > detailed timetable information in (that properly belongs in a GTFS feed or > somesuch, not OSM), just a broad-brush indication to help routing engines. > That's the beauty of it, my proposed tag can be detailed, but doesn't have

Re: [Tagging] Wind turbines: big and small

2013/10/7 Dan S > > (This > implies that tagging the height could be a solution... might be a bit > tricky to get correct height data though...) > What if the wind turbine is on the roof of a building? That would still be high (because we

Re: [Tagging] Wind turbines: big and small

Dana ponedjeljak, 7. listopada 2013., korisnik fly< lowfligh...@googlemail.com> je napisao: > On 07.10.2013 15:12, Janko Mihelić wrote: >> 2013/10/7 Dan S > >> >> >> (This >> implies that tagging the height could be a solution... might be a bi

Re: [Tagging] Wind turbines: big and small

Dana ponedjeljak, 7. listopada 2013., korisnik John F. Eldredge< j...@jfeldredge.com> je napisao: > > As far as I know, we don't have a standard method for tagging the height of an object mounted on top of another object, as distinct from the combined heights of the objects above ground, or the ele

Re: [Tagging] Wind turbines: big and small

Dana ponedjeljak, 7. listopada 2013., korisnik fly< lowfligh...@googlemail.com> je napisao: > No, if it is mounted on top I would say height=3 for the object. > > min_height is only used for building:part but not for explicit tagged > objects on top of another object. Please use ele=* to specify th

Re: [Tagging] Usefulness of bicycle=dismount on ways

I think dismount should be a key, not a value - bicycle_dismount=yes/no. On a typical sidewalk we have bicycle=no + bicycle_dismount=yes. On some pedestrian streets in Netherlands we have bicycle=no + bicycle_dismount=no When bicycle_dismount is not tagged, it is the same as foot=*. Bicycle=dis

Re: [Tagging] tourism=guest_house or tourism=bed_and_breakfast ?

I have come across tourism=apartments, there are 125 of them right now. Are those actually badly tagged tourism=guest_house? I think there's no real difference between them and guest houses. I like the sub-tags. ___ Tagging mailing list Tagging@openstree

Re: [Tagging] tourism=guest_house or tourism=bed_and_breakfast ?

I made a proposal for tourism=apartment[1] so we have a place to refine the meaning of this tag. I think the difference between apartment and guest_house is not very clear, but I guess apartments are a bit bigger, often have kitchens, and there are less of them in an apartment house then there are

Re: [Tagging] opening-hours: how to code "always but..."? Syntax diagram.

I think the best solution for your problem is: 24/7;Fr 00:00-14:00,22:00-24:00 I wouldn't use "off", I'm not sure a lot of data consumers consider it. Janko 2013/10/19 André Pirard > Hi, > > I've had multiple difficulties described > herecoding a

Re: [Tagging] Feature Proposal - RFC - Gambling

2013/11/14 Matthijs Melissen > > Hmm, difficult to get the difference right. How would you call a place > with video games and pinball machines? What if there are also claw > cranes? > I would draw the line when you can get more money (in cash) for less money. Getting a toy if you manage to claw

[Tagging] Bitcoin and Online shops

Hi, Openstreetmap has been contributing to the Bitcoin revolution with this map: http://coinmap.org/ the problem is that lots of online businesses want to get on the map, and I don't know what tags to suggest. Should we invent something like office=online? Then it could be further specified with

Re: [Tagging] Bitcoin and Online shops

Do we really want to delete this data? Is there any value to it? What they usually show is the website headquarters. So maybe a good tag is office=website_headquaters. 2013/11/26 Frederik Ramm > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > On 26.11.2013 22:31, Richard Welty wr

  1   2   3   4   5   >