Re: [Tagging] Emergency lane used by PSV at rush time

On 14.10.2012 15:35, Eckhart Wörner wrote: > Am Sonntag, 14. Oktober 2012, 14:40:45 schrieb Tobias Knerr: >> You could combine "Conditional restrictions" and the lanes suffix¹: >> >> lanes=3 >> >> access:lanes = yes | yes | no

Re: [Tagging] Turn Restrictions

14.10.2012 16:42, Martin Koppenhoefer: > 2012/10/14 Eckhart Wörner : >> I have now changed the page back to the last edit before Gauß started >> vandalizing, maybe some admin can lock the page as well? > > Has someone tried to approach him directly? On the Relation:restriction talk page, I've po

Re: [Tagging] How to tag: Legally separated ways

On 15.10.2012 10:56, Martin Vonwald wrote: > http://wiki.openstreetmap.org/wiki/File:Lanes_Example_2.png > > Only part 5 is relevant. Assume there is no physical separation just a > double line between the upper and lower two lanes. How would you tag > this: > a) One way with lanes=4 > b) Two sepa

Re: [Tagging] How to tag: Legally separated ways

On 15.10.2012 20:08, Colin Smale wrote: > I don't understand why emergency vehicles are so important in this > discussion. They are often allowed to ignore legal restrictions, but cannot generally ignore physical restrictions, so it's an obvious example where this distinction matters. But before

Re: [Tagging] How to tag: Legally separated ways

On 16.10.2012 01:07, Anthony wrote: > On Mon, Oct 15, 2012 at 5:23 PM, Tobias Knerr wrote: >> realistic rendering, particularly 3D "virtual reality". >> Physical separation and road markings look quite different from each >> other and should therefore also

Re: [Tagging] How to tag: Legally separated ways

Am 17.10.2012 00:18, schrieb Anthony: > On Tue, Oct 16, 2012 at 9:30 AM, Tobias Knerr wrote: >> On 16.10.2012 01:07, Anthony wrote: >>> As long as you have width information on the ways, I don't see the >>> problem. The amount of physical separation, whether it

Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?

On 17.10.2012 00:38, Eckhart Wörner wrote: > >> restriction = no_u_turn >> applies = no (to switch it off for all transportation modes) >> applies:hgv = yes (to switch it back on for HGVs) > > yeah, that's the idea. The implied default would be something like > "applies=yes, applies:foot=no" so t

Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?

On 17.10.2012 01:43, Eckhart Wörner wrote: > Am Mittwoch, 17. Oktober 2012, 01:31:00 schrieb Tobias Knerr: >> This trap would not exist with restriction:hgv=*, >> restriction:conditional=* and so on, because there you would not rely on >> an implicit default. > > I

Re: [Tagging] Lane dividers

On 17.10.2012 09:31, Martin Vonwald wrote: > Obviously we need some kind of tagging for lane dividers. Initially > when writing the :lanes proposal I though about reusing the divider > proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Divider > > But this has one serious drawback: if

Re: [Tagging] Lane dividers

On 17.10.2012 13:19, Martin Vonwald wrote: > 2012/10/17 Tobias Knerr : >> This problem does indeed exist, but it only appears with oneway roads > > I don't like something that only works in case a but not in b. This was merely meant as an interesting observation that I wan

Re: [Tagging] Standard for external links to location based services

On 18.10.2012 16:54, Simone Saviolo wrote: > However there is still the opening hours. > How would you use it on a map? Would you make a dynamic map in which > only amenities that are open *now* are drawn? One possible implementation for opening hours is to change icon color based on whether the a

Re: [Tagging] Standard for external links to location based services

On 18.10.2012 17:34, Martin Koppenhoefer wrote: > I think we have to differentiate here. Some of these services have > pages *about* an object (like foursquare, TripAdvisor, ...) and others > have pages maintained *by* the "object" (company etc.) itself, e.g. > facebook, myspace, twitter, ... > >

Re: [Tagging] Lane dividers

On 18.10.2012 21:56, Alberto wrote: > I think that tagging the effect is more important than the actual behavior > of the sign. > If you are in an unknown country, what would you like from your GPS, that it > gives you correct navigation instructions or correct rendering? Both. ;) In either case,

Re: [Tagging] Feature Proposal - RFC - Obstacle

On 23.10.2012 19:50, Konfrare Albert wrote: > I think that the voting phase could be opened, I shall wait five days. > If there aren't more suggestions or comments in these days, I will open > voting. Isn't it a bit early for that? Most uses of the obstacle key are still for values unrelated to yo

Re: [Tagging] Feature Proposal - RFC - Obstacle

On 24.10.2012 16:00, Konfrare Albert wrote: > Sorry, I'm following this page > , and > I thought that if there aren't suggestions or comments in two weeks, the > voting could be opened. You can open the voting, it's not against the

Re: [Tagging] Exclusive access rights

On 29.10.2012 12:51, Martin Vonwald wrote: > Masi, thank you for understanding my question. > > 2012/10/29 Masi Master : >> Hi! >> what about this: >> access:lanes=vehicle|vehicle|psv;hgv > > That is exactly what I'm not sure of. Is access=psv valid? I don't > think it is documented in the wiki i

Re: [Tagging] Feature Proposal - Voting - (highway=escape_lane)

On 04.11.2012 13:45, José Juan Sánchez del Arco wrote: > As I have seen, everyone dislikes the type=* tag, and I only noticed it > when you wrote about that. Honestly, I agree with most of you. So now we > have to wait until the voting is over, then I will change that and > reopen the voting time.

Re: [Tagging] Feature Proposal – RFC – Time domains

On 04.11.2012 19:05, Eckhart Wörner wrote: > The result can be seen in > http://wiki.openstreetmap.org/wiki/Proposed_features/Time_domains Does your new page take into account existing work on the topic? For example, there is a relevant and quite thorough specification with associated code hosted

Re: [Tagging] exit_to on motorway_junction

On 18.11.2012 19:08, Johan C wrote: > Unfortunately, exit_to is not documented. The destination in my opinion > has same purpose as exit_to, but is a better choice because you can use > it on both outgoing parts of the Y-branch and because you can use in in > conjunction with destination:lanes. Som

Re: [Tagging] Proposal: expanded address tags for US

On 18.11.2012 21:16, Steven Johnson wrote: > http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/UnitedStates I've looked through your slides and the proposal, but I do not yet understand why this solution is necessary. One of your examples is "6345 W. Euclid AV", which you would t

Re: [Tagging] exit_to on motorway_junction

On 20.11.2012 23:42, Paul Williams wrote: > I don't see any reason to deprecate exit_to, it seems to be the simplest > method of mapping a destination sign on a motorway junction or similar > exit. Isn't adding a destination tag to the outgoing highway fork just as simple? When you have two tags

Re: [Tagging] How to solve the problem with relation overload?

On 30.11.2012 11:29, Pieren wrote: > Or find > another modeling for routes (e.g. with intersection nodes only). That would actually be my preferred solution: Add the stops, and just enough nodes along the route to make it robust to calculate. It would require solid tool support, though. The curre

Re: [Tagging] Status of maxspeed:wet

On 04.12.2012 13:31, Pieren wrote: > On Tue, Dec 4, 2012 at 12:24 PM, Ronnie Soak > wrote: > >> Are you against changing things in general ... ? > > Not if the intent is clearly to deprecate an existing tag. I'm against > liars writing in the wiki that they won't change any existing tags > until

Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants

On 04.12.2012 13:23, Martin Koppenhoefer wrote: > 2012/12/4 Markus Lindholm : >> If there really is a need to bind address and POI together then create a >> relation for that. > > -1, this would be breaking a fly on the wheel (or shooting with > cannons on sparrows as we say in Germany). Really no

Re: [Tagging] POIs

>> On Sat, Dec 8, 2012 at 1:37 AM, Janko Mihelić wrote: >>> How would you connect POIs that have no address? You still haven't really answered this question which points out the (imo) most obvious flaw of the idea. Perhaps it would help if you gave us a definition of what you consider a POI. Wit

Re: [Tagging] Source tag - deprecated for use on objects?

> I have been told ( on the talk-US email list ) that use of > {{key|source}} on objects has been deprecated for years and that > such information is only of historical interest and its use should > be restricted to changesets. This is not reflected in anything I > can find on the wiki, and I've d

Re: [Tagging] Source tag - deprecated for use on objects?

On 02.01.2013 14:16, Chris Hill wrote: > Secondly, any changeset can have multiple sources so adding the source > tag to a changeset is not flexible enough. Any object can have multiple sources, so adding the source tag to an object is not flexible enough either. There are workarounds for either

[Tagging] Giant river multipolygons

Dear tagging list, as many of you may know, it is documented practice that riverbank areas can be split into several small parts, as illustrated in this image: http://wiki.openstreetmap.org/wiki/File:Make_river.png Nevertheless, there appears to be a trend to merge them into a single area for the

Re: [Tagging] Giant river multipolygons

On 29.01.2013 11:42, Pieren wrote: > On Tue, Jan 29, 2013 at 11:28 AM, Martin Koppenhoefer > wrote: >>> My opinion is your opinion: if there is no good reason for gigantic areas, >>> don't use them. >> +1, > > We already have "gigantic areas" for USA, Russia, India, China... > So just explain me

Re: [Tagging] Tunnels and bridges

On 31.01.2013 12:06, Martin Vonwald wrote: > I'm looking for some alternatives to map tunnels and bridges that > contain several ways. I'm not really happy with the proposed relation > [1]. Is there any other approach for this? I'm asking myself why don't > we simply map the outline of the bridge/t

Re: [Tagging] Tunnels and bridges

On 31.01.2013 13:24, Janko Mihelić wrote: > I like building=bridge. Not a good choice imo. According to a recent discussion, mappers might want to use that tag specifically to map buildings built into bridges - like these: http://ampelmann-restaurant.de/content/images/1a162245ce191485484b155c6eae

Re: [Tagging] Tunnels and bridges

On 31.01.2013 14:06, Martin Koppenhoefer wrote: > 2013/1/31 Tobias Knerr : >> http://ampelmann-restaurant.de/content/images/1a162245ce191485484b155c6eae79b9.jpg > > I wouldn't call this a "bridge", it is a vault, but the "bridge" (or > viaduct)

Re: [Tagging] Tunnels and bridges

On 31.01.2013 16:24, Janko Mihelić wrote: > I even drew it: > http://i.imgur.com/uk5RXjL.png > > So, a renderer could find out if a road that has the tag bridge=yes is > connected to a way that has a tag building=bridge on both ends. If it > is, it doesn't render the black lines on left and right

Re: [Tagging] Tunnels and bridges

On 31.01.2013 17:31, Janko Mihelić wrote: > I read a bit about 3D buildings, and it's pretty compatible. Here is an > article about simple 3D buildings: > > http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings I think you are overlooking several problems. To start with, building:part cannot do

Re: [Tagging] Tunnels and bridges

On 31.01.2013 18:39, Philip Barnes wrote: > Not splitting the way for every bridge will make tagging a lot easier. Won't anybody think of the poor renderers? :( Until now we could rely on the assumption that every way is *either* on the ground *or* above the ground. Which is pretty helpful imo.

Re: [Tagging] Tunnels and bridges

On 01.02.2013 07:22, Martin Vonwald (imagic) wrote: > We have a spatial database so if all features are within a closed way there > is no need for a relation. Why is there a different reasoning for a bridge? Because it is usually _not_ the case that all the features within the bridge outline poly

Re: [Tagging] Tunnels and bridges

On 01.02.2013 09:49, Martin Vonwald wrote: > 2013/2/1 Tobias Knerr : >> On 01.02.2013 07:22, Martin Vonwald (imagic) wrote: >>> We have a spatial database so if all features are within a closed way there >>> is no need for a relation. Why is there a different reasoning

Re: [Tagging] Footway as painted lane in highway

On 27.03.2013 05:18, Steve Bennett wrote: > It sounds essentially like a sidewalk - the only distinction being > that it's not raised above the road surface. So why not just use > footway=sidewalk? > > The footway=lane tag sounds nice, but it sounds like such a rare > occurrence that it will nev

Re: [Tagging] Feature Proposal - RFC - More Consistency in Railway Tagging

On 13.04.2013 08:11, Martin Atkins wrote: > http://wiki.openstreetmap.org/wiki/Proposed_features/Railway_Schematic_Mapping You are touching a tricky issue with a proposal that is honest about its limitations, so I welcome the constructive input. But unfortunately, I doubt it is the right way to go

Re: [Tagging] riverbanks wiki (was [OSM-dev] Coastline, lakes, rivers)

On 16.04.2013 16:46, Pieren wrote: > You say that "a redefinition of riverbanks has not been approved" but > the current wiki page says the opposite: > > http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank [...] > == New tagging == > A new tagging schema has been approved... > ... The ways

Re: [Tagging] Feature Proposal - RFC - (highway=bicyle_crossing)

On 18.04.2013 12:02, Martin Koppenhoefer wrote: > > 2013/4/18 Janko Mihelić mailto:jan...@gmail.com>> > > I think highway=crossing + foot=no + bicycle=designated is enough. > > we are turning in circles, it was already discovered in a parallel > thread that this tagging would prevent the cro

Re: [Tagging] Feature Proposal - RFC - (highway=bicyle_crossing)

On 18.04.2013 21:56, Alberto wrote: > >> It should not prevent this. We already use tags like bicycle=no on >> crossings, and they do not mean that bicycles may not travel along the >> street being crossed - only that this crossing is not for them. >> More generally, it would be wrong to assume tha

Re: [Tagging] When was barrier=entrance abandoned ?

On 08.05.2013 02:56, fly wrote: > On the wiki [1] barrier=entrance is marked as abandoned. Did I miss > something or was this another edit without discussion ? I don't remember a discussion about this. A problem with the edit is that entrance=* is not limited to the cases that barrier=entrance co

Re: [Tagging] Recreation_ground (landuse vs leisure)

On 27.05.2013 00:47, Greg Troxel wrote: > > Hannes writes: >> Sorry, I was not aware of that policy. I will discuss such edits in future. >> Please revert if they are unreasonable > > You should revert them yourself. If you aren't comfortable doing > reverts, you should not be running a bot. I

Re: [Tagging] Recreation_ground (landuse vs leisure)

On 27.05.2013 10:01, Frederik Ramm wrote: > Most "cleaners" become greedy with time. They start fixing a few typos > in their local area and before too long they make overpass queries and > fix "typos" world-wide without even thinking that the tag might indeed > be used differently in other places.

Re: [Tagging] cinema service_times

On 31.05.2013 21:02, René Kirchhoff wrote: > see http://wiki.openstreetmap.org/wiki/Opening_hours I'm not sure whether that really fits for the use case. Even if a movie is running 19:00-21:00, it is pointless to arrive at 20:00. This is quite different from a shop's opening_hours. So even though

Re: [Tagging] When was landuse=reservoir deprecated ?

On 06.06.2013 23:55, fly wrote: > We should use both landuse and water. The first for the whole area and > the later for the water area. [...] > Better use boolean (e.g. intermittent=yes/no). > > Maybe editors should warn or silently change these tags. > > Last but not least my question still rem

Re: [Tagging] Feature Proposal - Voting - Animal_breeding

On 16.06.2013 12:31, Martin Koppenhoefer wrote: > On 16/giu/2013, at 12:17, "Alberto" > So what’s now? Do you think I should create a definitive wiki page >> assuming the proposal is approved, although we have only 11 votes in >> total? I think you can treat it as approved. The requirement is "has

Re: [Tagging] Observations on use of the diet: tag

On 01.07.2013 17:32, fly wrote: > * I did add diet:lacto_free=* and diet:lactose_free=* I wonder what "lacto_free" is for. The diet:lactose_free key makes sense for people who aren't lactose tolerant, and the remaining milk-free market should mostly be covered by diet:ovo_vegetarian and diet:vegan

Re: [Tagging] Feature Proposal - Voting - image=http://example.com/image_license_page

On 02.07.2013 17:56, Bryce Nesbitt wrote: > http://wiki.openstreetmap.org/wiki/Proposed_features/Image > This tag has over 12,000 uses, and I feel it is time to define the > expectations for the tag clearly. Unfortunately, some crucial expectations that I have for linked images are still missing:

Re: [Tagging] RFC: toilets=yes, toilets:disposal, toilets:position and incoporating toilets:wheelchair

On 03.07.2013 03:10, Bryce Nesbitt wrote: > Discussion seems to have died down. Any last comments on > toilets:disposal and toilets:position before I open it up for vote? "byop" is not self explanatory. Wouldn't "paper_available" or something be more easily understood? You also list male/female/

Re: [Tagging] Feature Proposal - Voting - image=http://example.com/image_license_page

On 02.07.2013 19:17, Bryce Nesbitt wrote: > On Tue, Jul 2, 2013 at 9:33 AM, Tobias Knerr <mailto:o...@tobias-knerr.de>> wrote: > > * I feel that it should be stated that *only* images under a free > license should be linked, i.e. images that offer the same freedoms a

Re: [Tagging] type for natural=tree (leaved <-> leafed)

On 07.07.2013 18:47, fly wrote: > Am 07.07.2013 18:33, schrieb fly: >> Hey >> >> Could an BE-speaking person please tell me what the right spelling for >> broad_leafed is. Numbers are almost even in the data. Probably, a nice >> task for a bot. > > Sorry, numbers are towards "leaved". Numbers are

Re: [Tagging] type for natural=tree (leaved <-> leafed)

On 07.07.2013 18:59, John Sturdy wrote: > On further thought, I'd go for type=deciduous, rather than > broad-lea[fv]ed. Not quite the same thing (I think larches are > deciduous but not broad-leaved) but I think it's the normal "technical" > term (the others being "evergreen"). That would make th

Re: [Tagging] new tagging scheme for detailed information.

On 23.07.2013 07:38, amrit karmacharya wrote: > Over the last several months, we have mapped all the > We are now trying to upload these information in OSM. When we check at the > OSM wikis, we find tags do not already exist for all our data. For example, > tags do not exist for building structu

Re: [Tagging] incline default unit ?

On 11.08.2013 20:38, fly wrote: > In the wiki [1] it is written that the default unit for "incline=*" is > "%". Still I find almost non values without a unit with taginfo [2]. Well, it was perfectly clear that you should include the % ... "The value (given with the percentage-sign) is [...] Where

Re: [Tagging] Linking to Wikipedia subheaders

On 15.08.2013 17:24, Dominik George wrote: > The OSM wiki details that the syntax for linking to Wikipedia is de:Foo > for Foo in de.wikipedia.org . > > How can I link to a subsection? Would de:Foo#Bar be recognized? That link format is used within Wikipedia, so I think i

Re: [Tagging] Consolidating tags for building attributes

Hello Vivien, I develop a 3D renderer working with OSM data, so I will look at your questions based on that background. Case A: roof:material vs. building:roof The preferred key from 3D rendering documentation is roof:material because, as you guessed, it clearly differentiates this attribute fro

Re: [Tagging] Micro mapping traffic signals

On 27.08.2013 16:02, Pieren wrote: > My proposal: > - when micro-mapping the traffic lights, use a different tag than > "highway=traffic_signals" which should be reserved for the "simple, > old" fashion way of mapping the intersection itself. > - create a new tag for the micro-mapping of each indiv

Re: [Tagging] Housenumber interpolation with regularly skipped numbers

nding on the house number it starts with; step=1 would have the same effect as all). It will of course mean that current applications won't use your interpolation ways at all, but that's how it is supposed be when someone invents a new tag

Re: [Tagging] Housenumber interpolation with regularly skipped numbers

rs (e.g. missing "12") two ways > need to be drawn (e.g. "1-11" and "13-25"). This separation wouldn't be necessary according to your interpretation of interpolation, as the interpolation way wouldn't tell you whe

Re: [Tagging] Housenumber interpolation with regularly skippednumbers

t to map. If we use different tags, an application which needs to answer question 1 can evaluate both tags in the same way, while an application that answers 2 will only use the tag(s) for my interpretation of interpolation. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Housenumber interpolation with regularlyskipped numbers

ugh, so I can't tell whether that's a good idea. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The current problem with tagging

worst tagging problem we have to deal with in the long run, I'm not sure whether the definitions created this way wouldn't cause more problems than they would solve. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The current problem with tagging

e could then search their presets, too), but I don't think there is a more useful user interface for answering the "How do I tag y" question. By the way: We also have a German page for "natural language -> tags" in the wiki (http://wiki.openstreetmap.org/wiki/

Re: [Tagging] The current problem with tagging

ediaWiki or create your own app for browsing/searching (probably using the API (http://wiki.openstreetmap.org/api.php) together with some parsing to extract templates) is up to you, but I'd strongly recommend to use the wiki as your backend for most of the information. Tobias Knerr __

Re: [Tagging] The current problem with tagging

John Smith: > 2009/10/19 Tobias Knerr : >> I'd strongly recommend to use the >> wiki as your backend for most of the information. > > It doesn't matter how I look at the problem there will need to be a > lot of effort exerted to be useful. When I look at the

Re: [Tagging] The current problem with tagging

just think that duplicating information that is already present in the wiki or could easily be added to it (texts describing the meaning of tags, images and some basic information such as the "Element" and "Useful combination" sections from the default

Re: [Tagging] [OSM-talk] [tagging] Feature Proposal - RFC -(man_made=mineshaft)

n fact, I don't even think that you should explicitly set them at all, this should simply be the default case. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway property proposal "covered=yes"

Randy wrote: > I propose that an additional property for highway of "covered=yes" be used > for this and similar situations, where a road extends under a building, > roof attached to a building, etc. If I understand you correctly, this tag is supposed to be used for ways/areas that are *under* b

Re: [Tagging] How to tag un-named roundabout?

y not set a name tag for the roundabout. Keepright's assumption that every way with a highway tag needs to have a name is simply not adequate. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Implied oneway tag for highway=*_link, wiki edits

ure myself - for example, I'm still wondering how I should deal with this for my GraphView plugin -, but I'd like to know other people's opinions. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Comparison of tag support: Mapnik, Osmarender, Potlatch, JOSM, Kosmos, Map Features (wiki)

ing has split the "24/7" value for opening_hours. I'm not sure whether similar cases occur elsewhere, too. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Different speed limits

er most situations and allows to quite unambiguously store that kind of information. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Different speed limits

> maxspeed = 80 > maxspeed:{Sa,Su 11:30-18:00} = 60 correction (should use my glasses when typing brackets...): maxspeed = 80 maxspeed:(Sa,Su 11:30-18:00) = 60 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/t

Re: [Tagging] Different speed limits

_features/Extended_conditions_for_access_tags#Examples Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding housnumber the lazy way.

or tagging addresses in a way which can actually be parsed properly and doesn't rely on guesses by human observers. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding housnumber the lazy way.

#x27;s the very reason for the recent invention of the addr:inclusion key. By adding this tag with an appropriate value, you are basically opting out of that accuracy requirement. http://wiki.openstreetmap.org/wiki/Key:addr#Using_Address_Interpolation_for_partial_surveys Tobias Knerr ___

Re: [Tagging] Proposed definition for cycleways (was Re: bicycle=no)

ther highway values (e.g. bridleways, tracks, service roads, ... which can all be well suited to use by bicycles). Therefore, your definition could work as a separate tag, but not as a highway value - we only want one of these per way. Tobias Knerr

Re: [Tagging] What's a power=station?

e "station" value will be for what you would call a "substation". Tobias Knerr [1] http://wiki.openstreetmap.org/wiki/DE:Key:power [2] http://de.wikipedia.org/wiki/Umspannwerk ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tag proposal "image=http:/... .jpg"

ed on top of an OSM map), it's easy to set up your own database containing an association of image files with coordinates or OSM ids. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tag proposal "image=http:/... .jpg"

Ulf Lamping schrieb: > Am 05.02.2010 12:26, schrieb Tobias Knerr: >> Sam Vekemans wrote: >>> http://wiki.openstreetmap.org/wiki/Image >> The problem with this proposal is that there isn't a definition which of >> the several images that likely exist for most obj

Re: [Tagging] tag proposal "image=http:/... .jpg"

what you think about it! People will > use image=xy anyway as they already do ;-) Of course they will. I'm just posting this for the "told ya so" rights once we get "my image is nicer than yours" edit wars on images and quality/relevance criteria for image inclusions. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] opening hours

e are using increasingly more complex opening hours (seasonal, x hours after sunrise/sunset, holiday-dependent ...), so it's unlikely that any application will support all cases. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http:

[Tagging] Feature Proposal - RFC - Tree rows

Requesting comments for Proposal "Tree rows": http://wiki.openstreetmap.org/wiki/Proposed_features/Tree_rows natural=tree_row, used on a way, describes a line of trees. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/l

Re: [Tagging] opening hours

t "Aug Th[-1]" to mean "last Thursday of August". On a more practical note, I'd prefer the month and (nth) weekday substrings to be independently useable (to check whether the facility is currently open, compare month with current month, compare weekday with current weekday

Re: [Tagging] Utility overcrossings?

topic when I proposed a tagging for person conveyors (escalators, travelators)[1], but no one was interested in that topic afterwards. Therefore, the proposal is just sitting around as a draft. Tobias Knerr [1] http://wiki.openstreetmap.org/wiki/Proposed_featur

Re: [Tagging] game:patrizer2:* tags

cy. For example, Stockholm produces a lot of iron ore ("Eisenerz") and some fish. Apparently, this mapper decided to tag the production efficiencies to the cities' place nodes - which happens to be possible because the game uses real-world places. The data represented by the t

Re: [Tagging] Green areas that are not parks (revisited)

abstract classification. A typical residential landuse area contains many buildings, gardens and other associated features. So gardens can certainly be a part of a residential area, but they aren't residential areas themselves. Tobias Knerr ___ Tagging

Re: [Tagging] 'name' variation tags standardisation

alt:de equivalent? Oh, and personally, I even like "official_name" (which is the natural word order) better than name:official. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Billboards and other kinds of advert

#x27;t that simply a man_made=flagpole? Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Zone 30 (maxspeed)

al clause or phrase that a conditional statement uses. The phrase can either be true or false." That's because you can read these tags as *if* it is Sunday *and* I'm driving a hgv *then* maxspeed=80 applies Tobias Knerr ___ Tagging mailin

Re: [Tagging] paved=yes/no

. (That's even more true for the increasing number of editor preset users.) If you write an application or rendering style, don't worry too much about mappers sabotaging your style by inventing a new surface value for every road. You se

Re: [Tagging] paved=yes/no

On 19.07.2010 09:06, Steve Bennett wrote: > On Sun, Jul 18, 2010 at 2:42 AM, Tobias Knerr wrote: >> While the list of surface values is *potentially* unbounded, it is >> finite at any given time. For practical purposes, just teach that list >> of surface values on the wiki t

Re: [Tagging] paved=yes/no

on - this could be a part of the application itself, an osmosis task, a library or some other technical solution. I don't like the idea of adding this to the database, because I don't want to keep another tag up to date if it doesn't provide any info

Re: [Tagging] office=*

nters a feature for the first time doesn't produce quality results either. Getting a few people who care about the issue to discuss it and agree on a written result will produce good results, however. And the wiki RFC + voting process is a possible way to make

Re: [Tagging] office=*

John Smith wrote: > On 29 July 2010 15:13, Tobias Knerr wrote: >> 5-10k mappers doesn't work, but skipping discussion and inventing tags > > Don't confuse discussion with voting, voting is flawed and many things > are still discussed on the tagging list before be

Re: [Tagging] emergency=*

Yes, I have a problem with it: I don't see any advantage of having to remember both the key and the value used for an object type. Just leave stuff like this in amenity, that way we just need to know the value to tag it. "amenity" is the default key fo

Re: [Tagging] emergency=*

John Smith wrote: > On 30 July 2010 04:36, Tobias Knerr wrote: [...] >> stuff like this in amenity, that way we just need to know the value to >> tag it. "amenity" is the default key for features like this anyway. > > Which also means the amenity name space is pre

Re: [Tagging] tag groupings

ould be categorized. If there was a single obvious categorization that everyone would naturally use, then we might consider implementing that one. But this is obviously not the case. Tobias Knerr 1) natural=wood, for example, only later was clearly defined as the "untouched nature" tag th

<    1   2   3   4   5   >