Re: [Tagging] reference_point and landmark for addresses
Would not the problem with describing the position on the object be that you could still not find the reference object and thus it would be completely useless? If you have a location description referenced from big tree you need to find the big tree. There are multiple ways to get to the location from the reference point - one address can be north from big tree and south from small tree at the same time. We are used to take addresses as absolute positions, but this does not seem to be the case. You have absolute positions of reference points (should be in the map) and then use relative directions to get to the location - this is not an address and should not be tagged as one. Lukáš Matějka (LM_1) Dne 30. března 2012 10:11 Martin Koppenhoefer dieterdre...@gmail.com napsal(a): What about the established tag addr:full? This was intended for cases like this. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] reference_point and landmark for addresses
Right. So I just moved to proposal to https://wiki.openstreetmap.org/wiki/Proposed_features/reference_point The comments from Erik Johansson I posted on the previous proposal wiki page in order to not forget them in the future. As Lukáš explained I agree and as a first step i give priority to have just the reference points being markable as such. On 04/04/2012 09:15 AM, LM_1 wrote: Would not the problem with describing the position on the object be that you could still not find the reference object and thus it would be completely useless? If you have a location description referenced from big tree you need to find the big tree. There are multiple ways to get to the location from the reference point - one address can be north from big tree and south from small tree at the same time. We are used to take addresses as absolute positions, but this does not seem to be the case. You have absolute positions of reference points (should be in the map) and then use relative directions to get to the location - this is not an address and should not be tagged as one. Lukáš Matějka (LM_1) Dne 30. března 2012 10:11 Martin Koppenhoefer dieterdre...@gmail.com napsal(a): What about the established tag addr:full? This was intended for cases like this. cheers, Martin On 03/30/2012 01:50 AM, Erik Johansson wrote: I see why you would want to tag addr:reference_point=yes instead. Felix do you have any examples from real life? I think you should start collecting them, and please use Spanish since that is what the addresses are written in... Here are a some examples from real life: Example with a usual reference point: Nicaragua Guest House Bello Horizonte VI Etapa 217 Rotonda de la Virgen 2 cuadras al sur 2 1/2 abajo/west Managua, Nicaragua Example with a reference point, which usually would not be on a map: Ferretería Blandón Moreno Barrio Santa Ana. Del Arbolito 1 1/2 cuadra al norte (al lago) Managua, Nicaragua Example with reference point from the past: Colegio Filimon Ribera Reparto Schick De donde fue el Cine Ideal una cuadra arriba Managua, Nicaragua (Where Cine Ideal today is a Pizzeria) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Value separator
Hi, What is the best way to 'separate' values? I think about piste:grooming='classic;skating' or 'classic+skating'. Actually, this can be argued that this is a particular grooming type of crosscountry ski pistes, not a simple addition of a 'classic' and 'skating' grooming. So, is there any reason to prefer a semicolon or a plus? Yves ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Value separator
I would choose semicolon, because it is used already (even if not actually supported) LM_1 Dne 4. dubna 2012 23:16 yvecai yve...@gmail.com napsal(a): Hi, What is the best way to 'separate' values? I think about piste:grooming='classic;skating' or 'classic+skating'. Actually, this can be argued that this is a particular grooming type of crosscountry ski pistes, not a simple addition of a 'classic' and 'skating' grooming. So, is there any reason to prefer a semicolon or a plus? Yves ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Value separator
On Wed, Apr 4, 2012 at 4:31 PM, LM_1 flukas.robot+...@gmail.com wrote: I would choose semicolon, because it is used already (even if not actually supported) Yes, semicolon has existing support, at least in editors. Data consuming tools don't really support any form of multiple tag values though. Except possibly the MQ Open renderer... I think I've seen it parse multiple ref=* values out of US highways. Toby ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Value separator
yvecai wrote: What is the best way to 'separate' values? I think about piste:grooming='classic;skating' or 'classic+skating'. Reasons to prefer semicolon: Has been done that way for years. Is also documented in the wiki. http://wiki.osm.org/Semi-colon_value_separator Actually, this can be argued that this is a particular grooming type of crosscountry ski pistes, not a simple addition of a 'classic' and 'skating' grooming. If you consider your example a grooming type on its own, then of course you aren't looking for a value separator at all. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi, (sorry for starting a new thread, I just subscribed to the list) infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany, have developed an improved tagging scheme for TMC data which we would like to propopose to the OSM community. I believe this is much needed, so thank you for starting this effort. The one thing I like very much about the proposal is that it allows people to start using TMC information without spending too much time implementing insane heuristics or programming shortest path algorithms. However, I feel like there are some problems with your design, which should be discussed on a mailing list, since Wiki discussions are ugly. 1) The big problem: missing directional information Let's assume there is a way in OSM tagged tmc=DE:123+456;DE:456-123. One also has real-time traffic information that talks about a traffic jam at LCD 456, negative direction, extent 1. One therefore knows that this traffic jam affects DE:123-456, and since we have a way with that information, we know that this way is affected. However, there's one problem: which direction of the way is affected? It could be either the direction from the first point of the way to the last (called forward from now on), or vice versa (backward). This essential information is missing and makes the TMC information on non-oneway ways useless. There are several solutions to this problem. Probably the best solution is not using the tmc tag at all, but using tmc:forward and tmc:backward instead. Thus assuming the direction of the way is from LCD 123 to LCD 456, the tagging would be tmc:forward=DE:123+456, tmc:backward=DE:456-123. forward and backward are already used in tagging (for example, maxspeed:forward) and are also protected by tools. E.g. if you try to reverse the before-mentioned way, JOSM suggests to swap tmc:forward and tmc:backward (which is the correct thing to do in that case). 2) A matter of taste: + and - I'm not sure how others are feeling about this, but I find DE:123+456, DE:456-123 somehow confusing. Here's an alternate proposal: DE:123+456 becomes DE:123-456, and DE:456-123 becomes DE:123-456 (notice the changed order). Therefore, the LCD order is encoded in the position of the numbers, and the movement between the LCDs is encoded in the arrow. I would go even one step further and allow ← (LEFTWARDS ARROW; U+2190) and → (RIGHTWARDS ARROW; U+2192) as an *alternative*. I know that not everybody knows how to enter these codes, but every editor and every operating system nowadays should be able to display them, and we have full unicode support in the database. Because of 1), DE:123/456 does not make sense at all. 3) Bad influence: TMC information at junctions One thing that I cannot wrap my head around is the TMC information *at* junctions. As far as I remember, a traffic jam at LCD 456, negative direction, extent 1 affects the road *between* LCD 123 and LCD 456, but not the actual junctions 123 or 456. However, the rules of adding tmc tags to the actual junctions influence a lot of maneuvers going over those junctions but not using any other part of the way. This is especially true for roundabouts or junctions between dual carriageways. 4) Exits and entries TMC specifies messages that apply to entries or exits, which I feel are not adequately represented in the proposal, even though the proposal mentions them. For example, assume that the 2nd exit slip road going west at Köln-Süd (where I already discovered the new tagging) is closed (and I believe there is a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a really hard one.) 5) Versioning You argue that versioning is not needed, since data can be changed in a timely manner, and the errors that appear are mostly harmless. I don't feel that way: a) Experience tells that data is not always changed in a timely matter, especially since TMC data does not appear on most of the maps. It takes a while to process data (being half a month outdated seems to be normal even for online routing), and offline maps make this situation worse (just look at the bug reports at MapDust that appeared since Skobbler had started shipping offline maps). b) When LCDs are inserted into chains, things break *badly*, since the extents are then out of sync as well. Eckhart Wörner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
