[Tagging] landcover vs landuse
On Sun, Aug 16, 2015 at 1:27 AM, Friedrich Volkmann wrote:
> On 03.08.2015 00:55, Daniel Koć wrote:
>> I have just discovered that while landcover=trees has no Wiki page, it's
>> quite established tag (I wouldn't say "popular" here, because it's just
>> about 1% of forest/wood uses) and we could officially define as a generic
>> tag for trees areas, when it's not clear for the mapper if it's natural or
>> not ("forest" vs "wood").
>
> No, because the landcover=* key is just nonsense. There is no definition for
> that key. What does landcover mean? Vegetation? Soil? Atmosphere? Buildings?
> Ocean? Everything we map is landcover in some respect. You could use
> landcover=motorway instead of highway=motorway, and landcover=playground
> instead of leisure=playground. The landcover key matches all and nothing.
It's true that this key is mainly supported by a very small group. I
wouldn't say it is "established". The taginfo stats are relatively
stable and 760 users is peanuts 5 years after the proposal in OSM
(11/2010). One reason is probably because it's not rendered in main
map site.
But another reason is that most of the constributors draw such
polygons from the aerial imagery and they don't care about the
difference between land "use" and land "cover". When they see a piece
of grass or forest, they just want to draw a single polygon and use a
single tag for "grass" and "forest". Live must be easy for the
contributors. And promoting a new key which may replace or be combined
or partially overlap the old "landuse" will be extremely confusing for
the non-experts. And this will be endless, like the "footway vs path"
story.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting camp_type=*
On Tue, Mar 31, 2015 at 6:55 AM, Jan van Bekkum wrote: Not sure about the typo : is it "non-designated" or "non_designated" ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging established, unofficial and wild campings
On Fri, Mar 27, 2015 at 12:30 PM, Jan van Bekkum
wrote:
> Hi Pieren,
> I have mapped those myself only in cases other reasons
> existed to map than.
But this is not what the first section suggests:
"Beautiful place in the mountains, desert or at the beach - no
facilities, usually no explicit owner's permission ("wild camp"). We
can add attribute camp_site=trekking for trekking camps;"
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging established, unofficial and wild campings
On Fri, Mar 27, 2015 at 7:41 AM, Jan van Bekkum wrote: > We can use tourism=camp_site:non_designated for all cases that the area is > not (permanently or ad-hoc) designated. This included the following real > life cases: Jan, I really appreciate your efforts to find a consensus. But I couldn't agree on tagging such informal locations. It is so subjective, it can be set potentially everywhere in the countryside, everywhere you can install a tent. If the aim is to advertise a nice point of view, the risk is also that you encourage wild camping on the same place, increasing tourists attendance (and littering). The best location for wild camping is a beautiful and unique spot which was never used before you and will never be used after your night, no ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Accepted or rejected?
On Tue, Mar 17, 2015 at 3:04 PM, Kotya Karapetyan wrote: > I propose to clarify it by changing the recommended number of votes in > https://wiki.openstreetmap.org/wiki/Proposed_features#Approved_or_rejected > from "...8 unanimous approval votes or 15 total votes with a majority > approval..." > to "...8 or more unanimous approval votes or 10 or more total votes with > more than 74 % approval...". > This will not change anything in terms of the ongoing discussion of how the > approval influences other things. So the discussion can continue. But we'd > introduce some mathematical logic in the process. -1 The main criticism about "votes" is the "approved" status and the small amount of participants, not percentage of approvals. So change the status name and increase the quorum, not the opposite. It's also not a problem to keep the "vote" open for a long time. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)
On Wed, Mar 18, 2015 at 8:21 AM, Frederik Ramm wrote: I said few years ago that "vote" should be replaced by "opinion poll". This hasn't change in my view, > It is however not true that tagging votes are an important core element > of how we work; we can do perfectly fine without. Yes and no. It is not a core element but getting feedbacks before formalising a new tag is better than nothing even locally (like imports, no ?). But it is true that a tag "approved in the wiki" doesn't avoid bad tags. See the endless discussions around "smoothness" or "highway=ford" on ways or the use of abstruse abbreviations for the non-natives like "ngo", "aed" or "asl". > Even if certain things > were tagged differently in different parts of the word, that would not > break OpenStreetMap. Only a fraction of us is thinking like this. Using 2, 3 or 10 different tags for the exact same thing is surely providing a job for OSM consultants but is creating unnecessarily complexity for contributors and data consumers. Wikipedia wouldn't accept two articles on the exact same topic. It is our responsibility to keep the project usable, even for new data consumers. > "The following 35 people think that this proposal is a good idea and > would recommend using it" > rather than > "This proposal has been accepted" True. > So please, don't go over board here by trying to force-involve every > mapper in tag votes; they're simply not important enough, and they > *should not be*. Don't try to make them important, lasting, or binding. But the wiki is currently giving the impression that the "vote process" is formal and important. So something has to be changed. Btw, I don't think that translations will help. Some proposals don't have many feedbacks simply because the interest is not shared by a large group. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging established, unofficial and wild campings
"Informal campgrounds exist in areas where you are allowed to camp anywhere except... (like in Sweden) or where no rules exist" "informal campgrounds shall only be mapped if there is an important reason "... "Nearby presence of public facilities", "Their security", "Their sheer beauty", "Remote sites " which means potentially everywhere... imagine a similar proposal for pissing on trees tagged as informal toilets ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
I search an adjective about this tag and I hesitate between "very_bad" and "horrible" ;-) Btw, what's different today about its verifiability ? I think most of the people rejecting this tag simply ignore the discussions around it. This gives a different perspective about your "consensus". Removing the "controversy" section will just give the false impression that there is no controversy at all. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Super-keys are evil
On Mon, Feb 23, 2015 at 2:43 AM, Kurt Blunt wrote: > When you want to tag the same point with multiple categories, those > categories must share the same tag and be separated by a semicolon e.g. > shop=convenience;alcohol. That is, unless the two categories are under two > different super-keys, in which case the object will have a separate tag for > each category. This is inconsistent. We have other options than the semicolon e.g. "shop=convenience" + "alcohol=yes". We have noticed that excepted some rare exceptions (like multi-refs or opening hours), semicolons should be avoided in OSM because data consumers don't like them. > But nevermind the inconsistency. More importantly, this key-value tag > hierarchy makes it unnecessarily difficult for contributors to remember tags. > More specifically, it's difficult to remember under which super-key the > category is located. Is it building=shrine or amenity=shrine? Is it > barrier=city_wall or historic=city_wall? What about city_gate? Editors are supposed to provide some help tools like the presets where you type "city wall" and the editor finds the correct tag for you. Otherwise you can open the infamous wiki "Map features" page and use your browser "search" function. > Many tags don't even make sense. What does highway=track mean? Is it a > highway that acts as a track? A track is clearly not a type of highway. A > track is just a track. A contributor is left to feel like an idiot for not > understanding the logic behind this system. English is not my native language but I learned with OSM that "highway" has a modern meaning for main (inter-cities) roads but also an older meaning for any public road (http://dictionary.reference.com/browse/highway?s=t). I hope you feel less like an idiot now... > "amenity"="reception_desk" becomes "reception_desk"="", > "highway"="track" becomes "track"="", > "aerialway"="gondola" becomes "gondola"="", > "barrier"="city_wall" becomes "city_wall"="", > "historic"="city_gate" becomes "city_gate"="", > "sport"="volleyball" becomes "volleyball"="", > etc. A key with an empty value doesn't save much. And it can be worse and lead to misunderstandings. When you write "track=""", is it for cars or for trains ? Then you need a subkey again... I know one example following your idea: the "bus=yes" which can be used with "public_transport" or "access" keys but with different meanings (and no possibility to combine on the same element). In addition, you create much more work for the data consumers. The first example is the renderer who can render all buildings or all barriers in the same style, using a single rendering rule for all types of buildings or barriers which wouldn't be possible with your solution. I'm not saying the current system is perfect, we made mistakes (like the "tourism" category imho) but it's a compromise. And things can be changed (see "highway=ford" or "aed") although it's not easy and really needs good and valid reasons. > Now, I don't actually think such an overhaul is currently feasible given the > massive burden it would put on the database system. However, it might be > something to think about for the future. I think that after 10+ years of discussions, you are not the first who came with this idea. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecating aerialway=goods
On Thu, Feb 19, 2015 at 12:38 PM, Richard Z. wrote: > How is routing software supposed to know that some aerialway=goods are > actually taking passengers? like roads tagged with "access=no" or "private". Or "highway=pedestrian" not allowed for cars. We create simple tags for the average contributors, not to simplify routing software dev's life. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecating aerialway=goods
On Wed, Feb 18, 2015 at 2:49 PM, fly wrote: >> http://wiki.openstreetmap.org/wiki/Key:aerialway#Usage -1 I don't like such general keys like "usage" (or "type") in general. Basically, it could be used in all tags (e.g. highway=yes + usage=residential). It's not because it is now spread in railways that we have to repeat the same mistake (how about mixed usage ? again with the semicolon joke ?). An aerialway for goods is not the same as an aerialway for skiers. Until now, we use different values based on the different cabins/cars/lifts type. Perhaps instead of "goods" it could be replaced by "fork" or "container" or "container_for_goods", just enhancing the existing list following the same principle. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Voting - Water tap
On Fri, Jan 16, 2015 at 4:03 PM, François Lacombe wrote: > A fountain will striclty have the same external and internal design either > the water is drinkable or not. Here you join the other thread about "philosophy of tagging". Some people describe an object, others describe a service. You see a fountain or a tap and you don't care much if water is drinkable or not (you prioritize the object description above its functionality). But many other contributors, bikers for instance, want to find drinkable water points along the route and don't care if it's a tap or a fountain (functionality more important than the shape). Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Voting - Water tap
On Fri, Jan 16, 2015 at 1:06 PM, Marc Gemis wrote: > amenity=non_drinking_water ? Or "amenity=non_drinkable_water" + a subtag describing the object > It seems that amenity=drinking_water is cut into stone and we will never be > able to change this tag, although it obviously blocks more general tagging > scheme for water sources. I never said that. Although very hard, it is not impossible to deprecate a tag in OSM. We just need real good arguments for it. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Voting - Water tap
On Thu, Jan 15, 2015 at 4:13 PM, Kotya Karapetyan wrote: > As of today, a total of 16 votes have been submitted, 11 of them are > approvals. Since 2 weeks have passed and the required number of votes > (15) has been reached, I have closed the voting and will proceed with > clean up. Sorry but you could extend the period of feedbacks. 7 of the 11 positive "votes" came before the 13th january when I posted my comments about the possible issues (and the discussion forwarded here which probably drew more attention to more people). After this date the trend was much more balanced. You say you are aware of the clash with amenity=drinking_water but you don't explain how you will avoid this in your cleanup. You also agree that we need a rework but your proposal is just increasing the difficulties than solving them in the future. Now, for a water tap in the public space, it will be tagged with "amenity=drinking_water". And for the same water tap inside or near a cemetery, it will be tagged with "man_made=water_tap". How can we explain that to newcomers ? why "amenity" in one case and "man_made" on the other ? what is implied about potability ? etc Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic philosophy of OSM tagging
On Thu, Jan 15, 2015 at 9:13 PM, Kotya Karapetyan wrote: > There will be a tagging > committee: It will maintain the official OSM tagging scheme. Historical contributors and leaders will tell you that there is no "official committee" in OSM. But, to be a litle provocative, I would say we already have two committees for tagging scheme: - the JOSM presets maintainers - the DWG Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Voting - Water tap
On Sun, Jan 11, 2015 at 11:58 AM, Kotya Karapetyan wrote: > https://wiki.openstreetmap.org/wiki/Proposed_features/water_tap#Voting I voted earlier today 'no' to this proposal in its current state and provided my arguments. But now I'm asked to forward them on this mailing list (perhaps to see if I'm the only who disagrees). My main concern with the proposal is its collision with the existing "amenity=drinking_water" tag. And we get enough complains from newcomers about our tagging complexity to not create more confusion. The "amenity=drinking_water" tag is old and widely used (82.000 in taginfo). But recently some people asked how to tag water resource which is not intended for drinking like tap in cemeteries, see the question referenced from the "help" site ([1]). I fully agree that we need a solution here but it should not interfer with the existing tag "amenity=drinking_water". I did not follow the whole discussion but when I was called to provide my opinion on the proposal, the first sentence in the wiki says "This is a proposal for tagging of (publicly usable) water taps, such as those in the cities and graveyards. Water taps may provide potable and technical water, which can then be further specified with drinking_water=yes|no. " A bit later, there is a warning about fire_hydrant but nothing explains here clearly where is the difference between "man_made=water_tap"+"drinking_water=yes" and "amenity=drinking_water". And nowhere it says if "drinking_water" subtag is mandatory or not or what is the default value about potability. And we have seen in the past that with such ambiguities, a tag is very quickly improperly used by the community. Between the lines and comments, we see that some people would deprecate the older tag. Why not but then tell it clearly. What I don't like is what we have seen in the past with some proposals deliberately ambiguous about deprecating older tags because they know it is not very popular in the votes, and enforced the deprecation later, when the tag is moved to the "adopted" sections. I'm not personnally a big supporter of the amenity=drinking_water but I think the current proposal is not clear enough compared to the existing tags. Pieren [1] https://help.openstreetmap.org/questions/27869/how-to-tag-water-taps-not-intended-for-drinking-water ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Boundary Relations. What's a subarea used for?
On Thu, Jan 8, 2015 at 7:54 AM, Frederik Ramm wrote: > So yes, remove them if you are familiar with the mapping style in the > area you're editing and they are indeed unusual there, but leave them in > place if it looks like the standard operating procedure in the area. In France, we know only one person (maybe two) how is unfortunately very active to promote this role in boundary relations (and not only in our country). On our ML, we had much more people asking him repeatedly to stop it or at least use another relation but he never accepted this. So the concept of "standard operating procedure in some areas" has to be interpreted carefully. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Defining genre for public bookcases
On Sat, Dec 27, 2014 at 6:34 PM, Guillaume Pratte wrote: > What do you think? The wiki about public_bookcase has been validated by a public review but hasn't been converted to the correct template: http://wiki.openstreetmap.org/wiki/Proposed_features/public_bookcase Currently in OSM, we have 10 amenity=public_bookcase: http://taginfo.openstreetmap.org/tags/amenity=public_bookcase Seeing the numbers and the rarety of such feature, I think you can add your suggestion directly in your local editions and perhaps also in a new section in the wiki (noticing it's coming after the vote) Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Moveable objects tagged as building=*
Perhaps the attribute of 'moveable' or not should be specified in a separate tag (without significant deconstruction efforts or foundations because basically all buildings can be moved theoritically). I also don't see a problem to keep "building" for permanent structures, floating on water or on wheels (caravan). Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New openstreetmap-carto version: please check country and state boundaries
On Thu, Dec 11, 2014 at 12:37 AM, Janko Mihelić wrote: > We used to use admin_level=4 for counties, but were advised that > admin_level=6 is the standard. > > Anyway, we don't have states. Maybe you were talking about a different > country? I didn't find a level=3 boundary relation for Croatia either. But anyway, here is what is documented on the wiki: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative and we see several countries with a level 3. Anyway, you speak about a "name" and a "ref" for the relation. Since when do we need a "ref" for an admin boundary ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Main Distribution Frame added to man_made template
On Wed, Nov 19, 2014 at 1:35 PM, Martin Koppenhoefer wrote: > formally a tag to represent the whole building, it is defacto the only tag > for the whole site (mostly, I guess), and as such defacto representing also > the telco installation. If you want to map the locations of other service > equipment like DSLAM, OLT or PSTN, please use different tags (no > abbreviations or at least a generally understandable prefix like > "telecomunication"/"telco"). I don't remember any discussion about such tag on a global list. And we always recommand to not use abbreviations in tags since OSM tags can be read by any one, not only telecom experts (or any experts groups who love to exclude others by using a cryptic language). If it's coming from an import, the use stats do not reflect any significant adoption by contributions. It is then a defacto bad idea to validate an import mistake in the wiki ;-) Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] governmental / public_administrative landuse are not commercial
On Fri, Nov 14, 2014 at 12:29 PM, johnw wrote: > it is a subkey for the buildings, to go with building=civic. My concern is about splitting a landuse polygon just to refine information that could be stored on buildings themselves for instance. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] governmental / public_administrative landuse are not commercial
On Fri, Nov 14, 2014 at 5:03 AM, johnw wrote: > A couple more landuse cases were added. I’m going to ask now if it is a good > idea to specifically exclude Police/fire/safety and give them their own > landuse(s). I don't think we need a civic subkey in landuse. When I see the growing list, it will finally generate very small landuse polygons in OSM. This is not the intend of the OSM "landuse". We put "tax", "immigration" or "legislative" into the buildings where these services are. Otherwise, it is endless. We could create a subkey for "landuse=residential" with "residential=home" or "residential=garage" or "residential=toilets_in_the_garden" Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rooftop parking -> new parking=rooftop value?
On Tue, Nov 11, 2014 at 11:22 PM, johnw wrote: > 2014-11-11 12:53 GMT+01:00 Tobias Knerr : >> Therefore, would prefer a generic tag that can be added to any feature, >> e.g. location=rooftop. -1 'location' is already a bad keyword in OSM. Like "type", it is too generic and could be used for every thing. > On Nov 11, 2014, at 9:36 PM, Martin Koppenhoefer > Those are excellent ideas. Then you could use location=rooftop (or similar) > to place basically anything on the roof, including multistory or surface > parking structures. Garden roofs come to mind. I think the roof is part of the building 3d or levels mapping. We should not create a new use of "location" just for that. I could also imagine that in some buildings, the parking is somewhere in the middle and not necessarily on the top or on the bottom of the building, in which case you will have to invent a new tag for that. I would prefer something like "level=roof" or "level=3". Just where the parking(s) is in the building. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Digest, Vol 62, Issue 31
On Wed, Nov 12, 2014 at 8:50 AM, Mateusz Konieczny wrote: > No, unknown should be tagged as unknown. Even better - not tagged. +1 We don't tag what is unknown. Pierre ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] what does maxheight=none mean?
On Wed, Oct 29, 2014 at 6:24 PM, moltonel 3x Combo wrote: > And both tags are > definitive, whereas "maxheight:signed=no" (or whatever) is just > waiting for a better tooled or experienced mapper to do the survey. No. The survey is done : "there is no legal height restriction under this bridge". Of course, anyone is free to come back and add more tags like the physical height or the material and 3d shape of the bridge, etc. But the most interesting information for apps checking clearance (e.g. for routing) is there => no legal restriction here. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Default maxspeed unit on waterways
On Wed, Oct 29, 2014 at 3:47 PM, Malcolm Herring wrote: > On 29/10/2014 14:12, Ilpo Järvinen wrote: >> >> I don't know about other countries, but here in Finland the water maxspeed >> signage is in km/h although knot is used for almost everything else. > In UK waterways, both MPH and knots are used. Usually MPH on canals and > knots on rivers, though even this can depend on who the navigation authority > is and how far back in history their statutes were written. Okay, if the unit is not generalized, then my idea doesn't make sens. Sorry for the noise. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Default maxspeed unit on waterways
On Wed, Oct 29, 2014 at 2:52 PM, Tom Pfeifer wrote: > km/h is derived, at least with an integer multiple of seconds, > from SI units. mph and knots are not. I would prefer to keep > one default unit per tag, consistently, everything else leads > to confusion. What is leading to confusion is to suggest that km/h is the default unit for waterway speed when knot is in use everywhere. Please think as a contributor, not as QA programmer or data consumer (it's easy to check if the speed limit belongs to a waterway or not). And "The knot is a non-SI unit that is "accepted for use with the SI" (https://en.wikipedia.org/wiki/Knot_%28unit%29) Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Default maxspeed unit on waterways
Hi, Currently, le wiki ([1]) suggests that maxspeed has to specify the unit "knots" when it's not km/h. But "knot" is the unit used worldwide on waterways. Why should we add something obvious on all waterway elements ? Could we suggest that the default unit for maxspeed on waterways is "knot" and the default "km/h" remains for highways and railways ? Pieren [1] http://wiki.openstreetmap.org/wiki/Key:maxspeed ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] what does maxheight=none mean?
On Wed, Oct 29, 2014 at 1:51 PM, Marc Gemis wrote: > So why can't we fill in the default value for unsigned bridges explicitly , > so e.g. maxheight=4 and add source:maxheight=:default ? I don't know the max height in my country. And probably most of the contributors don't. So the simple "maxheight=unsigned" or "unmarked" or "whatever" is easier for the average contributor. What you suggest is possible and could be automated. But it could be done by the data consumers as well. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] what does maxheight=none mean?
On Mon, Oct 27, 2014 at 8:21 PM, Friedrich Volkmann wrote: > (...) But when we see nothing, it's plain wrong to add something to the > database. But it's a common practice today in OSM. It seems you missed the long discussions about "noname=yes" or "oneway=no". Such tags don't say "here is nothing". It says that someone went on place and checked that the restriction does not apply. Otherwise, we cannot differenciate surveyed locations and missing information in OSM. Btw, I'm also in favour of "maxheight=unsigned" which is for me less controversial than "maxheight=none" (even as a non native English speaker). Although "maxheight" is the legal value (like all tags in the category "access"), "none" is suggesting that there is no height limit at all. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - relation type=person
On Wed, Oct 15, 2014 at 11:34 AM, Ilpo Järvinen wrote: > Not that it would interest me personally to find some distant relative's > grave, but I've been on multiple occassions on with somebody who has been > looking for a grave of a relative "that is supposed to be somewhere here". > Clearly they didn't known where that relative was buried. Often the search > even terminates without success because there are simply too many graves > to look at. We could have the same discussion about names on appartments entries or mailboxes. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - relation type=person
On Tue, Oct 14, 2014 at 2:58 PM, Ilya Zverev wrote: > Hi! I've noticed today there is an epic voting battle on the fields of > wiki. Hundreds of mappers came to state their disapproval of person > relation type. I wonder how many of them actually mapped one, or even > seen such relations. I found some of them in 2011, and posted an entry > in SHTOSM about such relations. After at least three years, this > proposal is not about new relation type, and you should understand > this. Well, they are plenty of tags in OSM that nobody has ever heard excepted his creator ... It's not because we don't use a tag that we cannot give an opinion. And I cannot remember any public discussion about such 'person' relation type, at least on the international lists which could explain why it is coming under the spotlight only today. > There are 1648 relations of type=person already in the database. But if I believe some feedbacks, most of them have been created by only three contributors which is tempering the stats. > The proposal is basically about documenting a relation type. > It either can be found in the wiki, or not. Nobody here has the power > of removing all such relations from the database. The database is the result of our consensus. Of course anyone has the power to add any thing but others have the same equal power to remove them. (The question is more about making a mass insert or a mass delete). If I find personal data on my own family in OSM, I will delete them immediatly without any permission. > Some say, you cannot make something appear in the database just by > passing proposals in the wiki. You should do some mapping first. You can add new tags directly in the database. And you can write anything in the wiki. But it does not mean that the whole community will accept your idea. Some might, some might not, most will ignore you. This proposal is questionning the limits of OSM, it is not really related to some physical element on the ground and is about privacy. > Well, > poles have been mapping for 4 years. Is it enough? Or should they have > waited another 4 years, so there are 10k relations of this type? It is > a part of OpenStreetMap, whether you like it or not. It won't go away > if you vote "no" on the proposal, and there won't be less such > relations added. So this is not about a new type. This is about > documenting something that has been mapped for years. But if the "vote" (I prefer "feedback") is showing that a significant part of the community does not like the idea, then you cannot refuse that they will delete one of such relations when they meet one of them. (mass deletion has to be treated differently) > And now, this far into mapping "persons" in OSM, you should not > prevent documenting established relation types, but help document them > better. In one way, you say it is already widely used and in the other way, you admit it could be better documented. I will show you where we have problems in the proposal and why a "vote" process is sometimes better than simply enforcing an idea. I copy the description here: "The main purpose of this type=person relation is to link (bind) different objects describing a person in the data base (such as grave, memorial place). " Here clearly, the graves and memorials are mentionned as examples. The relation could be used for everything related to a person and we find now such relations linking e.g. a grave with all streets using that person name. First mistake : it has not been strictly limited to graves and memorials. "That kind of relation is meant to describe dead persons. For a living people that kind of relations should be created only if it is reasonable. " Second mistake : it has not been strictly limited to dead people. It's really encouraging contributors to use this relation for everything related to a person. "Let's assume that good reason for creating that relations is "encyclopedity", that means existing of article about a person on Wikipedia. " Third mistake : It is not strictly reserved for "notable" people and can be used to name all graves in a cemetery (which might be forbiden in some countries). Privacy is never mentionned. To solve this, you could enforce a link to wikipedia because they are already an "encyclopedia" and check people notability (http://en.wikipedia.org/wiki/Wikipedia:Notability_%28people%29). And once you create a link to wikipedia (or wikidata), you don't need the relation anymore- Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - relation type=person
On Mon, Oct 13, 2014 at 6:55 PM, Paweł Marynowski wrote: > The idea was to reflect, the best we can, situation with graves. This is not clear in the proposal. It's much more than graves. Birthday, family, description, etc. If you check examples, it is reused to add every details of a person live (memorial, named streets) > A lot of people mentioned Wikidata. Do you know the rules of Wikidata? There > are notability rules[1], so it's simply not possible to store information > about every person there. This is another question but not about this relation. We have to be careful about creating a database of named people (and their relationship) when they are not celebrities. Even for dead people, it can be conditioned to local legislation. > I will be more than happy to find better solution to map graves like this > not using relations. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - relation type=person
Hi all, Within 2 weeks, I discovered the "person" relation on this ML and found another (local) thread questioning the pertinence of this relation in OSM. Because an OSM relation collecting all information about a "person" is not something obvious for me and this idea has never been really discussed globally, I moved the wiki page back as a proposal and would like to open a vote about this and get your feedback here: http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:person#Voting Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=bridge
On Fri, Oct 10, 2014 at 8:51 PM, Clifford Snow wrote: > On Fri, Oct 10, 2014 at 11:47 AM, Martin Vonwald >> To tag or not to tag, that is the vote! ;-) > Help me understand how we get to a document tagging standard on the wiki > without voting. Is there a threshold for when a tag become acceptable? I > think I understand that voting is problematic with the low number of votes. > However, I'm not sure waiting until enough people use a tag is practical > either. The process called "vote" is probably not appropriate. But it is the best method we have to get a feedback from the community and an attempt to reach a consensus. If you don't do this, the risk is that several people suggest different solutions/tags that will later coexists in the database (which is always a mess to fix). Another one is that your documentation is not found by the others and never reused. Or that your tag is used for something else. Or that your description is too vague and open for wrong interpretation. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Water tap
On Fri, Oct 10, 2014 at 7:13 PM, sabas88 wrote: > Perhaps it's nonsensical but... > http://taginfo.openstreetmap.org/search?q=entrance%3Dexit It's like Microsoft story where you have to click on 'start' to stop windows... But it is not because someone didn't make the best choice that we have to follow him... Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named
On Tue, Sep 30, 2014 at 8:56 PM, fly wrote: > Once more cite a mail on the previous thread [1] > > Seems to be a real world example, which is mappable with nodes for the > traffic_signals and an area for the junction. You even don't need an area if the junction is a node and the traffic signals are also using their own nodes (thus different osm elements). Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging for graves?
On Tue, Sep 30, 2014 at 6:04 PM, Brad Neuhauser wrote: > In addition, there is a type=person relationship [4] which appears to be > recommended for this kind of use. This is typically stuff that are not related to any geographic feature. It's really using OSM just as a free access database, bypassing the restrictions of wikipedia. Something that could be deleted without regret on both database and wiki. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named
On Tue, Sep 30, 2014 at 2:21 PM, Janko Mihelić wrote: > If there is a need to tag traffic signal names and junction names on the > same node, As far as I understood, this is just a theoritical case. Also, in real world, it doesn't make real sens to name the intersection AND a traffic signal (with different names). So I would suspend this point until a real case appears... Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
On Wed, Sep 24, 2014 at 8:16 PM, Pee Wee wrote: > No it not a language problem or a dictionary issue. It's about an OSM data > consumer (openfietmap) that thinks it is important to for cyclist to know > what type of paving can be expected. Paved, unpaved and semi-paved to keep > it simple. I think this is OK and it works for me. I think the main issue raised in this thread is to decide if each data consumer can decide alone what surface is paved or not (using this "surface" key and its hundreds values) or if we are able to find a common definition stored in the osm db (using this "paved" key). With the first option, the "paved" attribut can be inconsistent between applications. With the second option, the "paved" attribut is subject of personal interpretations from the contributors but this could be moderated when the surface key is also present. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] name and brand tags
On Wed, Sep 24, 2014 at 5:07 PM, Martin Koppenhoefer wrote: > -1, if the name tag has values that aren't actually the name of the tagged > instance it should be removed. This is not about compatibility, but cleaning > up "tagging for the *-data-consumer". It's not tagging the data-consumer/renderer. Most of the contributors don't care about the real oil station (or hotel or bank) name/brand/operator refinements. We should consider the tag "name" as the main key and tolerate that name duplicates brand/operator until someone updates it with the real station name. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Soapy) Massage Parlour
On Tue, Sep 23, 2014 at 4:56 PM, Mishari Muqbil wrote: > I've also been advised that Thailand is not the only country with this > legal concept and that as we should be mindful and cautious of this. But in OSM we map what's on the ground. Create a new tag like "amenity=brothel_even_if_it_is_not_legal_to_say_it_is_one" or "brothel=dont_tell_anyone" Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse=grass => natural=grass
On Thu, Sep 18, 2014 at 7:57 AM, Friedrich Volkmann wrote: >> 1. I thought the general consensus was to start using landcover for this >> type of object. > > No consensus. I strongly oppose landcover=* in view of its weak definition, > and because it invents nothing new. Say, how does landcover=grass differ > from surface=grass? I think the consensus is to stay as simple as possible and use only one tag to say that there is grass on this piece of land. Most of the contributors don't care if the magic keyword is "landuse" or "natural" or "surface" or "landcover" for that and most of them wouldn't agree to draw different polygons or use several key to make such small subtleties. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Personal Keys for WikiProject, Survey Data for Import
On Thu, Sep 18, 2014 at 8:35 AM, Alex Rollin wrote: > How do I know/get-notified it was changed? > Specifically, how would you setup a system to receive notification that the > object was changed? > Have you done it? Do you have some scripts to share? (Can I please NOT > have to add a relation?) > We are talking about many thousands of nodes, btw. If the ID is a "personal ID", not something used by externals, then why simply not using the OSM element id itself (node id or way id or relation id) ? >- OSM is not an storages for external IDs, the external DB should link to OSM >objects >- use wikipedia / wikidata links Who can decide that wikidata is not an external ID which shouldn't be stored in OSM ? Why wikidata couldn't link to OSM objects ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Tue, Sep 16, 2014 at 8:53 PM, Lukas Sommer wrote: > For the junction! > > For a named junction with a (not named) traffic signal: junction=yes + > highway=traffic_signals. (Quite common on Korea – on the ground, not in the > database.) Ok, I improved the wiki about this :http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Named_traffic_signals.2Ftraffic_signal_systems_.28Japan.E2.80.A6.29 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Tue, Sep 16, 2014 at 6:38 PM, Lukas Sommer wrote: > Currently in OSM we use yet > highway=traffic_signals for traffic signal names in Japan. And we use yet > junction=yes for junction names in Korea. Sounds easy but... how do you tag a named junction with a traffic signal ? highway=traffic_signal + junction=yes + name=* means that "name" is for the junction or for the traffic signals ? And can we imagine a case where the junction and the traffic signals are both named (and possibly differently) ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] include smoothness=* in JOSM presets?
On Mon, Sep 1, 2014 at 11:16 PM, Mateusz Konieczny wrote: > There are some sidewalks with allowed cycling but completely decayed paving > stones and there > is no better way to tag this. There are also some asphalt roads with really > bad surface. etc etc. I didn't check your application but the smoothness tags in Krakow. This way for instance is a good example: http://www.openstreetmap.org/way/37702408 smoothness=good on a pedestrian highway (also with a "bicycle=yes"). You added this tag in changeset 24356171 . I guess your intention was to specify a good smoothness for bicycles but others could interpret this tag as simply good enough for pedestrians... Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] include smoothness=* in JOSM presets?
First, most of the people using presets (JOSM or ID) don't read the wiki. Tags have to be self-explanatory as much as possible. And even if you explain that "smoothness=excellent" is for roller blade, I know skaters that could use "smoothness=good" ways easily. And I'm still waiting some clarifications between "very_bad" and "horrible"... We also had long discussions about reducing/simplifying the list of values... I would also like to see at least one application using it, if any. > I am not really happy about it, but I was unable to invent something better > and it > not as bad as say maxspeed:practical. Do we have to choose between bad and worse ? As already mentionned, the skater, biker or car driver will have a totally different idea/view of what a "good" or "bad" smoothness is for his means of transport. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Archway
On Sun, Aug 31, 2014 at 10:25 PM, Martin Koppenhoefer wrote: >>> The key landmark might be a possibility, for example, landmark=archway? >> Prefer to have it in some other name space as not all might be >> significant landmarks. Additional landmark=yes or landmark=archway might >> be ok > +1, I have in the past used for (much smaller and older) arches man_made=arch +1 for man_made. "landmark" is too vague. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] default value for "oneway"
On Fri, Aug 29, 2014 at 12:48 PM, ael wrote: > To suggest that we now have to include every possible tag with an > explicit value on every element is just ridiculous: the logical > consequence of an explicit oneway on all ways. +1 The rule is and has always been in OSM the following : "if oneway tag is missing, we assume it is not a oneway" (excepted for roundabouts: and we had epic discussions about the default for motorways but finally it was said that we should add it explicitely also there). I can understand it is disturbing newcomers and people coming from GIS. But once you understand the concept, it's easy. Of course, adding explicitely that a street is not a oneway, especially in a dense area with many oneways make sens. It's just telling the other contributors that this particular attribut has been verified by someone. But don't ask others to make it mandatory. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] leisure=common
On Thu, Aug 28, 2014 at 5:17 PM, Dave F. wrote: > I believe it was withdrawn as it vague. You logic is stated on one of the > pages you posted. It was in the "map features" page for years : "An area where the public can walk anywhere (UK) " I guess it is also used in US. I found some examples : https://www.google.fr/search?safe=off&hl=fr&site=imghp&tbm=isch&sa=1&q=village+common&oq=village+common&gs_l=img.3...11667.13247.0.13578.8.7.0.0.0.0.476.476.4-1.1.00...1c.1.52.img..8.0.0.cFS7KjyXTyo If you don't know what "village common" is then don't use it. If we start to delete all vague definitions in the wiki, we should better start with "smoothness" :-) Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] leisure=common
I find a bit harsh that leisure=common has been completely withdrawn from the wiki "map features" in the middle of the summer. If it's a UK specific tag, then move it to a special UK map features page/table, no ? http://wiki.openstreetmap.org/wiki/Template:Map_Features:leisure http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Religious landuse
On Tue, Aug 26, 2014 at 6:35 PM, Tom Pfeifer wrote: > If you want to expand the meaning of this tag you would need a migration > strategy, > but I don't see it necessary. "landuse=religious" is consistent with > "commercial" > or "retail", where you can have different retail amenities or businesses on > the area. OSM tagging is not perfect, but we do not introduce a new > inconsistency > with this tag. Religious areas can fit into a general "landuse" like "residential" (or even why not "commercial", "retail", etc). It's not exclusive (where another landuse polygon is normally). Also I remember the time we always said that landuse is intended for small scale mapping, not a parcel scale. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map Features template
On Tue, Aug 26, 2014 at 7:36 PM, John Packer wrote: > Some people like these templates because it seems they can make new tag > values appear in non-english pages by adding them in the english page. > But this new value appears in english, so in my opinion it kinda defeats the > purpose of the non-english page... The purpose of such templates was to have the same list in all languages. If someone introduces a new entry, it's spread in all local pages. It's probably not translated immediately but it is by far much better to see it in English than to have to maintain manually separated pages/tables. We don't have enough active wiki contributors for such solution. The tag pages came later and probably many of them are even not listed in the Map Features where we only show the most popular and commonly agreed tags. We can also sort and group them differently from a simple alphabetic order or key string. Not something we can "program" easily. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Religious landuse
On Tue, Aug 26, 2014 at 5:25 PM, Tom Pfeifer wrote: > Thus the comparison with [amenity=school], that can be easily expanded to > the > whole campus, fails for [amenity=place_of_worship]. > > Thus, an active church building should be tagged > [amenity=place_of_worship] > [building=church] > [religion=*] > and surrounded by > [landuse=religious] > [religion=*] I'm not following you here. Active or not doesn't change the fact that now we have two different ways for tagging an amenity and its surrounding area when we compare with "school", "hospital", "university" or wahteveramenityyoulike. We don't need a "landuse=school" because the amenity=school is already covering the area, not the individual buildings. We have to follow the same logic for all features. The problem is that amenity=place_of_worship rendering is for a building on the main map style. This could be fixed by using a differente style/colour/transparency if the tag "amenity=place_of_worship" is combined or not with a tag "building=*". It's extremely sad and dangerous to create a precedent now just because we have a rendering issue for one of the "amenity" keys. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RENDER
On Mon, Aug 25, 2014 at 8:36 PM, André Pirard wrote: > Yes, this sentence is misunderstood, and by many repliers apparently. > It means that once Mapnik uses a (defined) rendering you cannot change it > (RENDER is ignored). > The main idea behind RENDER is not coloring objects, and I agree it > shouldn't, but showing them. > And the renderer can do that with any single color they like. > > Basically, all renderers already decide what they print or not. Adding a flag saying "hey don't forget my feature" will not change this principle. Also with your tag, the same feature may or may not be displayed on the map, depending if you added your RENDER tag or not. Your proposal have no chance to be adopted for these reasons. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] minus or underscore in attribute values?
On Sat, Aug 23, 2014 at 12:25 PM, Martin Koppenhoefer wrote: > the space gets replaced by an underscore +1 The problem is not to have a preference between underscore and hypen but to know if our English colleagues can agree on the separator space or hyphen. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] usage of maxspeed:practical is described as recommended on wiki
I would modify the section [1] by replacing "it is recommended" by "it is suggested" and adding at the end a note saying that a large part of the community consider these two tags -smoothness and maxspeed:practical - too subjective. Pieren (I also suspect the 12000 coming from some imports. Such numbers do not say many thing if we don't know how many contributors really used it). [1] Marking surface of road with tag surface without adding it to parallel roads (or adding only tags surface) may lead to unwarranted understating priority of road relative to surrounding[1]- so it is recommended to add also proposed tags smoothness=* and maxspeed:practical=*. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Forest vs Wood
On Thu, Aug 21, 2014 at 10:29 PM, Andrew Guertin wrote: > landcover=forest > anywhere there's trees on the ground > landuse=managed_forest > where logging activity occurs or the forest is otherwise closely > tended by humans > natural=wild_forest > forests without much human activity, either because they're > protected or because they're far away from humans So, after 7 or 8 years of confusion about 2 main tags for "forest", the best idea now is to introduce a third one... Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Fwd: Information board details in bus stops
I forward my question here because I think my first attempt was done on the wrong list (tran...@openstreetmap.org) : > Hi, > > How would you tag an information board in a bus stop and mainly, if > there is a timetable, map, etc. > > This picture on twitter suggests new tags: > https://pbs.twimg.com/media/BvUsqMEIMAA3VRf.jpg > > "information:name", "information:map", "information:timetable" > > I didn't find an existing wiki proposal for such details. My question is about the information board/boards at bus stops which someone tries to tag in details in his French city (think about disabilities). Accidentally, on the transit list, the tag "strip=yes" was also questionned (check the picture). I guess it's about the road markings on the road itself where the bus actually stops (but not sure, it's maybe also something for blinds). Someone on the other list suggested to replace it by "road_markings=yes". Any other suggestions about this and the information boards ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping cave tunnels passable by human
I'm afraid that the main problem here is not the use "location" or "layer" or "cave" but "highway=path". This tag was created for multiple vehicles ways, not exclusive to a transportation like footways or cycleways. Currently the wiki tries to reflect this in the "path" definition: "A route open to the public which is not intended for motor vehicles, unless so tagged separately. This includes snowmobile trails, ski trails, hiking trails, horse trails, bike trails and paths, mountain bike trails as well as combinations of the above and other modes of transportation. " Unfortunatelly, this tag was abusively (impov) reused later for climbing routes. And now for caving. But none of these activities are open to the main public, requires special skills and equipments (incl. for survey) and, as already mentionned, needs a better handling of elevation data which is not easy in our model. I'm afraid that the main reason to not create new "highway" tags was/is to see them immediately on the rendered maps... That's why I would prefer something new like "highway=cave" (or whatever you like) without any additional mandatory tags like "location=underground" (correct me if I'm wrong but a cave is always underground). That would not be immediately visible on the map but data consumers requesting "all highway path in Poland" could also safely ignore this creation. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] convert imported natural=rock areas to bare_rock
On Sun, Jul 13, 2014 at 5:54 PM, Friedrich Volkmann wrote: > Unfortunately, I am no politician who can spend all of his time for campaigns. If you plan a mechanical edit exclusively in France, you should at least send a message to the local list (e.g. talk-fr@; even in English) to inform the local community about your intentions. It is not politics but basic courtesy. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Kindergarten, Childcare and Preschool
On Mon, Jul 28, 2014 at 10:57 AM, Andreas Labres wrote: > Additionally, preschool (FWICT) could be expressed as > > amenity=school, age=5-6 No, the "age" might greatly differ depending in which continent/country/educational system you are. This can only be an indicator and country specific (but could be summarized in a "per country" wiki page like we do for admin_levels) Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Religious landuse?
On Thu, Jul 17, 2014 at 10:32 AM, Martin Koppenhoefer wrote: I'm surprised about this discussion. Think that amenity=place_of_worship has to be treated like amenity=school. Nobody is asking to create a landuse=school because it is rendered properly on the main osm style. The problem is that amenity=place_of_worship is always rendered as a building even when it could be a bigger area (like for schools). Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "Relations are not categories" excepted for "type=network" ?
If you don't understand that a collection of "all bus routes from operator XYZ in my city" is not different than a collection of "all McDonald's restaurants in my town", then I cannot argue any more. And if we tolerate the first, we cannot refuse the second. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "Relations are not categories" excepted for "type=network" ?
On Wed, Jul 16, 2014 at 6:33 PM, Jo wrote: > I'm having a look at it. It could of course be converted automatically. > Since I have the scripts to walk through the hierarchy already. Again, I'm not asking to delete them *right now*. I'm checking if the proposal is "fair" and is not breaking the "relations are not categories" principle. If no, I could modify the wiki and recommend some solutions (like using query the appropriate tags on the collection itself instead of creating a relation for that). Existing relations could be modified along the way when people are contribution around them. @Frank I agree that the wiki should formalize the practice but not all practices in OSM have to be followed. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "Relations are not categories" excepted for "type=network" ?
On Wed, Jul 16, 2014 at 5:23 PM, Paul Johnson wrote: > On Wed, Jul 16, 2014 at 9:57 AM, Jo wrote: >> We are talking about numbered node NETWORKS, where a network relation is >> entirely appropriate to describe the network of nodes and the routes >> connecting them. Numbered node cycle networks are not very different from a bus network in a town. Instead of numbered and signed junction nodes, you have numbered (or named) and signed stop positions. The only difference is that a bus line is not choosing its destination at each junction. In your case, you don't have a predefined list of (master) routes but only a list of path "segments". But again, like "all bus routes in a town" or "all motorways in a country", you should be able to retrieve the whole list of smaller routes and junctions with an appropriate set of tags on the nodes and route relations. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "Relations are not categories" excepted for "type=network" ?
On Wed, Jul 16, 2014 at 3:02 PM, Jo wrote: > We have been tagging these networks this way since the beginning of > Openstreetmap.org. The network relations combine the nodes and the route > relations for a given network of numbered walking/cycling/horsback riding > network. Please, give me an example where the nodes cannot belong to the route relation and need specificaly a "network" relation. > Just like Marc I've also been doing it this way since that is how it was > described on the wiki. The wiki is just a "proposal". I don't remember it was discussed on any global list (checked in my archives). It was surely not discussed in France and the examples I find are personal initiatives. > And I admit this was to make it possible to download the whole bunch in one > go with JOSM. I appreciate this honesty and I could even accept such thing in earlier OSM time where we missed the tools we have today (like overpass). > The combination of route and network relations works and it is an elegant > solution for this type of numbered node networks. The network relations are > not categories as such. This is where we differ. The "netwok" is just an attribut like many others (operator, branch). We don't accept this kind of collections for restaurants, banks, etc. and we have to be consistent and refuse it for routes for the same reasons. > Just like you aren't able to change how PT is mapped, because of too > 'complex' when rendering the beast, you won't be able to change this. So let > it be or remap them all yourself. While you're at it, also make sure all the > route relations become continuous once again. This is something I'm doing > every once in a while, as route relations break easily. I created scripts in > JOSM to help perform this task. I don't feel like rewriting these scripts, > just because you want to change how these networks have been mapped since > the very beginning. It's not the question to "remap everything" but move the network name down from the relation to its members. My intent is not to remove all of such relations but see if we can reject this proposal and provide a better solution in the wiki. Then advise my local community to not use them (and remove them in long term). > You can't expect everybody to read this mailing list, which is kind of moot > anyway, just like the imports list. It's always the same. Once we have a conflict between mappers, you need a meeting point where everyone can express his opinion and put all arguments on the table. What is writen in the wiki can be the result of such discussions. Note that the wiki provides a "discussion" page and this proposal was already objected since 2009... ([1]) Now, I wanted to see some real examples and followed the ones linked in the wiki: http://www.openstreetmap.org/relation/20614 : type=network network=road description=Deutsche Bundesautobahnen" operator=Bundesrepublik Deutschland all members are route relations; route=road; tagged with operator=Bundesrepublik Deutschland This could be fixed by adding the tag "network_name=Deutsche Bundesautobahnen" in the route relations. http://www.openstreetmap.org/relation/153968 type=network network=iwn name=Camino de Santiago The first member is a route relation: http://www.openstreetmap.org/relation/1247178 type=route route=hiking name=Voie de Soulac And, oh surprise, it belongs to 2 network relations. The second one is: http://www.openstreetmap.org/relation/3071561 type = network network=iwn name=Way of St. James name:es=Camino_de_Santiago http://www.openstreetmap.org/relation/157868 type=network network=rcn name=Gooi en Vechtstreek More interesting, it's containing a mix of nodes and relations. Check the first relation: http://www.openstreetmap.org/relation/150267 type=route route=bicycle network=rcn Check the first node: http://www.openstreetmap.org/node/45909336 Well, it belongs to the same route relation... My conclusions so far: The relation is not used consistently : sometimes you have a "name", sometimes just an "operator" or "description"; the values of the "network" key are inconstant. The relation for all motorways in Germany is only a collection/category. The "Camino de Santiago" is basically a "route master" linking smaller route segments together. It's even worse here since the same long route is modelized twice in the database... The bicycle network example shows that the nodes are finally on both types of relations. This could be simplified with a tag like "network:name". Shall I continue ? Pieren [1] http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Network ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Religious landuse?
On Wed, Jul 16, 2014 at 1:52 PM, John Packer wrote: > Does this seems correct? It's something else and is related to a "rendering" issue. The place_of_worship area is rendered as a black area on the map and is usually placed on the building polygon. If you want to draw to whole place which can be more than the building itself, then you have this "rendering" issue because you see no difference on the map. Instead of creating a new tag, this could be fixed in the rendering style sheet where the color and transparency could be different if the polygon place_of_worship is combined or not with a "building=*" tag. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "Relations are not categories" excepted for "type=network" ?
On Wed, Jul 16, 2014 at 11:54 AM, Marc Gemis wrote: > right now the nodes are not placed in the route relation. Although some > older relations might contain them. Then you admit it is possible to keep the nodes in the route relation. Where now you have two relations instead of one just to avoid a tag "network:name". Don't tell me again it's to avoid a repetition of tags, we do this for many features in OSM. It's not for simplicity : the whole structure is more complicate to understand (more relations and different levels). Again, the real reason is to avoid a query in the database. > I think you will not find a lot of people in favor of changing the tagging > scheme for those networks, just because you don't like the network relation. > Anyway, if you want to change it, I propose you write a proposal with all > the required changes, and post them to the Belgian, Dutch and German mailing > lists and forums. I think this single list and the wiki, instead of ten local lists and forums, is more appropriate, no ? I don't have preconception about such relation, if someone find a valid argument/example which explains it's not using relations as categories. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "Relations are not categories" excepted for "type=network" ?
On Wed, Jul 16, 2014 at 11:27 AM, Marc Gemis wrote: > > Just thought of this: since a node can belong to multiple networks (cycling, > walking, equestrian), we need a tagging scheme for the network name that > takes this into account. > So something like : network:rcn:name, network:rwn:name and network:ren:name No, the tags on the node should be moved to the appropriate route relation where you also set the network_:name. > both rcn and rwn are already used in the numbering of the nodes (rwn_ref, > rcn_ref). I'm not familiar with the equestrian networks Is this question related to the "network" relation ? > Another problem is for routes that form the connection between 2 networks. > Right now, they are placed in the 2 network relations. How would you tag the > network names for them ? Create two route relations, one per network. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "Relations are not categories" excepted for "type=network" ?
On Wed, Jul 16, 2014 at 11:07 AM, Marc Gemis wrote: > So we get network:name, network:operator on each node and route, right ? Since "network" is already in use for "rwn/rcn/etc", its name could be set in something like "network:name" or "network_name". I don't see the point with "network:operator" where "operator" is already used. But tell me if you know an example where the network operator is differente from the hiking route operator belonging to this network... Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "Relations are not categories" excepted for "type=network" ?
On Wed, Jul 16, 2014 at 8:17 AM, Jo wrote: > The same is true for cycling and equestrian networks with numbered nodes. > There are a few of those networks in Germany as well. > These are not collections/categories. They are networks of route relations. Well, you could do the same for all McDonald's restaurants in Netherlands or all pharmacies in a network or bank branches in Belgium and say "we move one tag to the upper relation to avoid its repetition". What is done by such relations can be done by a query in the database with one or two arguments (like the "operator" or "network" tag) and a bbox (see XAPI, overpass, etc for more info). Repeating the network or operator or brand name is not a problem for many features in OSM. I don't see why we should create an exception for footway routes. As it was writen by Frederik Ramm in 2008 ([1]): "Our database is a spatial database; this means that it has intrinsic knowledge about the location of objects. If you want to know about all footways in East Anglia, simply pass in a bounding box of East Anglia and request all footways, and the collection is made for you on-the-fly." Pieren [1] http://wiki.openstreetmap.org/w/index.php?title=Relations/Relations_are_not_Categories&oldid=179750 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] "Relations are not categories" excepted for "type=network" ?
I discover that OSM contains 1575 relations of "type=network" (taginfo). I guess its definition is coming from this wiki proposal: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Network Quotes: "A network groups together routes that share common characteristics, e.g. a common operator, a common classification scheme (e.g. E-road network: "E 1", ..., "E 999"), ... " "Use cases Person A sees a bus route with number 217 and wonders how many other bus routes exist in that city. Renderer M wants to render all German motorways using white font on blue sign (official layout), and all E-roads with white font on green sign. This can be implemented by adding rules for 20614 (view, XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx) and 20645 (view, XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx). Renderer M wants to render all cycle routes that belong to the "D-Netz". However, there are a lot of other national cycle routes as well. " Plus some attached relations examples very explicite. As raised in the "discussion" page, is that not exactly breaking the "relations are not categories" ([1]) principle ? Can we delete such relations when we meet them ? Pieren [1] http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Proposed Node Relation
I think here you just try to compensate the missing 'z' component in OSM. I don't see any problem to have over two elements on the same position if they have different "ele" or "layer" values. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering change: buildings within highway areas
We get increasing feedbacks on my local list that the new rendering rule is counter-intuitive (to not say that it is considered as a bug). Now roads are rendered on top of buildings even when roads are really under buildings or underground (tunnels). Why not when your primary interest is for roads, but it's not so nice when your interest is buildings ;-) Examples: http://www.openstreetmap.org/#map=18/47.61190/-122.33067 http://www.openstreetmap.org/#map=19/43.28450/5.38016 This is now clearly a map style oriented for transport and the result is more abstractive than previously where the z order reflected more the real world. We can blame Google for many things but, at least, they render tunnels below the buildings... If you don't like buildings, than make it frankly and remove them completely from the style. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Track grades
On Tue, Jul 8, 2014 at 9:39 PM, Volker Schmidt wrote: > The combination of tracktype, surface and smoothness could fit the bill. You cannot expect that any renderer will be able to display all possible combinations of these three keys and dozen values. Or you map is unreadable. > However smoothness values are ill-defined and would need more objective > classification, but they also refer to things like high-clearance vehicles > http://wiki.openstreetmap.org/wiki/Key:smoothness Excepted if you can provide a special device measuring the road smoothness, it will never be objective. Forget the "smoothness" tag please. We might replace it by the 4wd tag (but it's only a partial solution) or another passable tag (for city car, 4wd, mtb, etc) Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering change: buildings within highway areas
On Wed, Jul 2, 2014 at 8:46 PM, Georg Feddern wrote: > Did you consider buildings that are - at least partly - raised on > pillars/columns with a pedestrian area underneath? I think such buildings should have a tag "layer", no ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subsequent wikipedia links
On Tue, Jul 1, 2014 at 4:42 PM, Andy Mabbett wrote: > A Wikidata ID is part of a URL and can be rendered as such; for > example, Q173882 equates to <https://www.wikidata.org/wiki/Q173882> It was said at the beginning that wikidata or wikipedia tags will never replace OSM tags but now I see counter examples or duplicates of what is already there (like on this scary proposal for the operator, architect, brand, artist, subject, name etymology [1]) . This is what I call "seeing the OSM project through wikipedia eyes". Since I'm not a wikipedian, I don't care about such tags if it remains below the noise level but I hope we will be able to avoid their proliferation in OSM (e.g. this growing list of "wikidata:" prefixed tags). I guess the next step could be to rely on wikipedia for the translations but OSM has to stay independant, even if it makes wikipedians unhappy. > It's not "unusable"; see URL, above. Consider the contributors that never heart the word 'wikidata' and how they can understand the tag "wikidata=Q173882". It's not a tag I could describe as self-explanatory. > An example I've given previsouly is that the Wikidata entry for > Q173882 (which is St Paul's Cathedral in London) links to the > MusicBrainz entry for the cathedral, and that tells us which musical > works have been premiered there. We wouldn't want to use OSM to store > lists of works premiered in the buildings we map. OSM is open for all new tags. Once we admit wikidata references, what would prevent someone to add the MusicBrainz or freebase.com reference directly in OSM ? Why should we accept one and not the others. Where is the breaking point ? Pieren [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subsequent wikipedia links
On Mon, Jun 30, 2014 at 1:36 PM, John Packer wrote: > The main reason is that the wikipedia key is well established and supported > in some sites, which either point a link to it or use some image from the > page. No, the main reason is that the wikipedia key is still human readable where the wikidata is just an encrypted interdatabase foreign key. I would consider elements exclusively tagged with wikidata as a pollution (or -at least - incomplete constribution) in OSM, like any other unusable 'ref's to external resources. And one of the mentionned example is providing the building operator only through the "wikipedia:operator" where most of the data consumers are simply looking for the "operator" tag. I discover a semantic shift where traditional OSM tags are slowly replaced by wikipedia contributors eyes and habits. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging of a throughabout
On Sun, Jun 29, 2014 at 7:11 PM, Lukas Sommer wrote: > Am I right? FYI, we had a recent discussion about roundabouts controlled by traffic lights on this list: http://gis.19327.n5.nabble.com/Signal-controlled-roundabouts-td5808587.html Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Former tram lines: disused, abandoned or razed?
On Wed, Jun 25, 2014 at 9:37 PM, Martin Koppenhoefer wrote: > +1 to your analysis > "razed" doesn't literally exactly represent rails being buried under an > asphalt layer, maybe abandoned for all of it? -1 Asphalt covered parts are not visible, not used and speculated. The result for such mapping will be an excessive segmentation of the highways only for historical purpose (would be the same if someone changes the "surface" tag every 10 meters). I would suggest to map such things on historical map projects. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=pipeline - is onewayness implied?
On Fri, Jun 20, 2014 at 5:22 PM, fly wrote: > Better use an own tag like flow_direction=forward/backward/both/none or > similar. This way we will cover all three cases mentioned below. Where is the difference between "flow_direction=forward/backward" and "oneway=yes" ? or "flow_direction=both" and "oneway=no" ? About "flow_direction=none", then you water stream/canal/pipe is not a water stream/pipe/canal (change the primary tag). Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviewing the use of addr:housename
On Thu, Jun 19, 2014 at 10:14 AM, Serge Wroclawski wrote: > Paul, if you'd read the actual instances of addr:housename that I > provided earlier on this thread, then you'd have seen that the name > field is already being used for the POI itself (as it should be). But this is a mistake. "addr:housename" has not been created to replace "name", "operator", "brand" or "addr:housenumber". As the wiki says, it has been created for houses without numbers and designated by a name. If you build an address for a POI, you need all tags "addr:*" plus the POI "name". We don't have to duplicate the POI name into "addr:housename". Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Signal-controlled roundabouts
On Wed, Jun 18, 2014 at 1:42 PM, Janko Mihelić wrote: > I've never heard of this "turning circle" term. Maybe we should call this a > turning circle, and then beg routing application developers to treat it the > same as roundabout. Currently, the wiki suggests to tag equally both types of junctions ([1]). To avoid confusion, we could use a specific tag like "junction=traffic_circle" (already 33 in taginfo) (then we could discuss about the "oneway=yes" implied or not). But I don't think that routing applications are checking right-of-way's. Pieren [1] http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout#Signal-controlled_Roundabouts ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Pipeline bridges
On Wed, Jun 18, 2014 at 11:28 AM, Martin Koppenhoefer wrote: >> I expect that it would be [man_made=pipeline, location=overground, >> bridge=yes, layer=*]. > +1 -1 I would expect "bridge=yes" to be combined with highways only. Here nobody can walk/drive on the pipe. We don't call it a bridge. "location=overground" is enough. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "No abbreviations in names" edge case
After a quick search: http://web.archive.org/web/20011218005945/http://www.kwtv.com/news/strange/ixl.htm it seems that the name **is** an abbreviation (and "for what" is lost), in which case you don't have to expand it. (perhaps add a tag "note" to explain the case...) Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Signal-controlled roundabouts
On Wed, Jun 18, 2014 at 10:43 AM, Pieren wrote: Btw, we also have some special cases like this one: http://www.openstreetmap.org/#map=19/47.20880/-1.58741&layers=N where a tramway is crossing the roundabout. It's a normal roundabout (not a traffic circle) excepted that traffic lights stop the road traffic when the tram is crossing the junction. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Signal-controlled roundabouts
On Wed, Jun 18, 2014 at 8:38 AM, Volker Schmidt wrote: > Only relatively recently (1984) the French introduced the roundabout with > priority in the ring. Today, most of the roundabouts in France are ... roundabouts where traffic in the ring has right of way and they are tagged with "junction=roundabout" (perhaps 99% of the rings). Since years our community (and drivers ;) is aware about the difference with "traffic circles" (no signage, with or without traffic signals) with priority to the right (traffic entering into the ring). The famous "arc de triomphe" in Paris is one of these junctions which are today the exceptions ([1]). Pieren [1] http://www.openstreetmap.org/way/184551793 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Signal-controlled roundabouts
On Sat, Jun 14, 2014 at 9:41 AM, Philip Barnes wrote: > This roundabout originally had no lights, but they were added with the > ring road. Interesting. Now you get the disadvantages of both systems : you have the unnecessary waitings on red lights and you use a maximum of land space for a junction... Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Door Values
On Wed, Jun 11, 2014 at 1:44 PM, Martin Koppenhoefer wrote: > > My suggestion therefor is to be more explicit with the key identifiers, > e.g. > * door_type (or door:type) for hinged / sliding / revolving / ... (still > this is somehow ambiguous, because "type" might also be interpreted as > "glass door", "wooden door", ...) > > -1 where is the difference between door=* and door_type=* ? very confusing for newcomers. I would prefer a "door=yes/hinged/sliding/..." + "automatic=yes" or "manual=yes" (saying default is manual) 'not sure about door=opening means... Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic question about functional classification of highways
On Sun, Jun 15, 2014 at 4:00 AM, Fernando Trebien wrote: > For several applications, such as navigation software, a distinction > would be very interesting, allowing the display of rural primaries and > secondaries when zooming out, a more accurate speed guess when the > maxspeed tag is missing (based on these tables, which seem to assume > that the urban/rural boundary is mapped using a place=* tag, perhaps > an old idea: > http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed). > The only benefit I can see of mixing the two classification systems > into a single system is not being required to duplicate a rendering > rule. If you tag differently urban roads and rural roads, where is the difference between using two "highway" values or simply two "maxspeed" values on the same "highway" ? Btw, I never understood why the "maxspeed=:" was not simply a "maxspeed=" since OSM is a spatial db and knows in which country the way is. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki edits, building tags on nodes versus areas
If the whole building is a shop, I see no reason to not reuse the same OSM polygon for both features (the building and the shop). However, if the shop is not the unique entity, like apartments/flats on upper floors, I also recommended in the past to use a node. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] noexit=yes wiki page update
All arguments are on the table. Nothing new here but a recent change in the wiki removed what was accepted as a compromise in april. There is not conceptual mistake to say it's a cul-de-sac on the node or on the way. Providing the information to QA tools or other contributors on the last way or on the last node is equal. And please read again the comment from Frederik Ramm: https://lists.openstreetmap.org/pipermail/tagging/2014-April/017405.html I don't understand why some people are not accepting simple things and facts : we have currently 198.000 noexit on nodes and 119.000 on ways. So I'm not the only one who think differently than you and enforcing that on the wiki is really offending the intelligence of these contributors. And even if you fiddle the wiki, you will not enforce contributors to use the tag on ways. What will be you next step ? delete the tag in all ways ? And what will be next ? delete all "oneway=no" because it's useless most of the time ? Pieren To André, I did not reply to your last message in our private conversation because I was simply not able to understand your arguments, even with my best efforts. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Urban perimeter
On Tue, May 27, 2014 at 5:55 PM, Martin Koppenhoefer wrote: > I see, for this you'd most probably need a new boundary type (if it isn't > the same as your administrative boundaries). +1 type=boundary + boundary=? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Urban perimeter
On Tue, May 27, 2014 at 3:37 PM, Fernando Trebien wrote: > I like Nelson's idea of using a new value for "boundary" to represent > this, mainly because the perimeter is not "ground truth" but an > invisible "legal definition" that roughly matches the urbanized area. > I was wondering if this concept exists elsewhere so that we can even > propose such value in a way that's reusable worldwide. That's the point. Is it "legal" or just the sum of all urbanized "landuse" 's (residential, industrial, retail). Does it include backyards, garden, orchard, etc ? The limit is often clear on the road (first/last building + road sign) but fuzzy on aerial imagery if you want to draw the area. And if all landuses are already mapped, do you add a new polygon reusing existing nodes or do you create a multipolygon relation (splitting the existing landuse) or you just collect the sum of existing landuses ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] capital and state_capital: how are they being used in your country?
On Thu, May 15, 2014 at 2:23 PM, Matthijs Melissen wrote: > Some more strange cases: We could create an additional role (e.g. "capital") when the "admin_centre" is not the capital (and only in this case to avoid unnecessary duplicates). Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] boules=petanque vs. type=petanque
On Thu, May 15, 2014 at 11:07 AM, Dan S wrote: > "type" is far too vague - it doesn't namespace at all, so it doesn't > make it definite if it's a type of boules, a type of pitch, etc. The > english wiki says, and I concur, Key:type "should be avoided": > http://wiki.openstreetmap.org/wiki/Key:type > Much better to standardise on the "chaining" approach i.e. "boules=*" > (or "boules:type=*" would have been another possibility in a parallel > universe). Luckily, the number of petanque objects is small enough > that it's possible to harmonise, so long as the nations can agree :) +1 I don't like the key "location=*" for the same reasons. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] capital and state_capital: how are they being used in your country?
On Thu, May 15, 2014 at 11:31 AM, Martin Koppenhoefer wrote: > btw.: The current definition for administrative relations says that > admin_centre should be used one or no time in the relation, but what if > there is more than one admin_centre, e.g. entities where the administration > is split over 2 (or maybe more) places? My suggestion would be to change > this part of the relation definition in order to allow special cases: > http://wiki.openstreetmap.org/wiki/Relation:boundary Why not. But the definition shall be clear : it's only the administrative(s) centre(s) "place(s)" to be linked. The risk if we don't specify a limit is that contributors will use it to link "all" places within the boundary (making a substitute of the infamous "is_in" tag). Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
