Re: [Tagging] [OSM-talk] Instead of voting
2009/10/12 James Livingston : > If there is a wiki page which describes a tag in a limited way, and I > want to document how I've used it, what should I be doing? IMHO you should either try to find out that your definition of the tag is the one the majority of mappers supports (and uses), or you should invent another tag. > * edit the main page, which could annoy the people who created the page +1, you shouldn't do this without discussing it first if you are changing the actual meaning of a tag, or better: you should invent another tag to describe what you want to express. > * add a note to the discussion page, which someone searching the wiki > for how to tag things won't read +1 > * create a new page describing my version, which leads to conflicting > information no, this is IMHO counterproductive, as different pages with different content/definition for the same tag will 100% lead to chaos. IMHO you should generally invent a new tag if possible. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/13 Gilles Corlobé : > Hello everybody, > > I propose to add a tag "boundary=military" : the problem is that, with the > existing tags, it's almost impossible to mark correctly lots of data, like > (non limitative list) forest, scholl, parking lot, … > > Rather than multiplying the "military=*" tag, I suggest to only mark the > external limit of the military area. > > http://wiki.openstreetmap.org/wiki/Proposed_features/Military_base This does not sound completely strange, but still incorporates some problems (all currently tagged landuse=military will get deprecated). I don't see the big problem here, as you can 1. draw a landuse=military around the whole area (and probably military=barracks) 2. draw a landuse=forest around the actual forest 3. draw a landuse=school around the actual school (or building=school for the school-building) 4. draw and tag the parking_lot where it is. IMHO landuse=military is already what you want to express with boundary=military. The boundary-object can be tagged as barrier=fence/wall/whatever with entrances, gates, videosurveillance etc. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Visual map for the blind
2009/10/12 : >> >> What tag would you use for bus/tram stops with a "i" button that reads >> >> out the information about trams soonest to arrive, aloud? >> > >> > I have never seen those before. >> > >> > Not proposed yet, but I guess many things need explanation, >> > so I would tag it like that: >> > >> > tourism=information >> > information=acoustic_text >> > description:en:blind=There is an information button that reads out >> > schedule times >> >> It doesn't seem like a tourism thing to me, wouldn't they be designed >> for people that live in the area? > > Well, ordinary maps and tactile maps are used by people living in that area, > too, but the "information" tag is placed in "tourism". > That does not matter, because we can display elements from any namespaces on > any map. while this is true, it might still facilitate life for editor-creators and data-consumers as for mappers to have all these kind of tag subsummarized in one big tag like k=disabled v=* or k=accessibility, v=* so you can easily find them in one rubrique instead of searching all over the wiki in different tags and pages. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/13 Martin Koppenhoefer : > 2009/10/13 Gilles Corlobé : >> Hello everybody, >> >> I propose to add a tag "boundary=military" : the problem is that, with the >> existing tags, it's almost impossible to mark correctly lots of data, like >> (non limitative list) forest, scholl, parking lot, … >> >> Rather than multiplying the "military=*" tag, I suggest to only mark the >> external limit of the military area. >> >> http://wiki.openstreetmap.org/wiki/Proposed_features/Military_base > > This does not sound completely strange, but still incorporates some > problems (all currently tagged landuse=military will get deprecated). > I don't see the big problem here, as you can > 1. draw a landuse=military around the whole area (and probably > military=barracks) > 2. draw a landuse=forest around the actual forest > 3. draw a landuse=school around the actual school (or building=school > for the school-building) > 4. draw and tag the parking_lot where it is. > > IMHO landuse=military is already what you want to express with > boundary=military. The boundary-object can be tagged as > barrier=fence/wall/whatever with entrances, gates, videosurveillance > etc. What about using a relation to add secondary land uses? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/13 John Smith : >> This does not sound completely strange, but still incorporates some >> problems (all currently tagged landuse=military will get deprecated). >> I don't see the big problem here, as you can >> 1. draw a landuse=military around the whole area (and probably >> military=barracks) >> 2. draw a landuse=forest around the actual forest >> 3. draw a landuse=school around the actual school (or building=school >> for the school-building) >> 4. draw and tag the parking_lot where it is. >> >> IMHO landuse=military is already what you want to express with >> boundary=military. The boundary-object can be tagged as >> barrier=fence/wall/whatever with entrances, gates, videosurveillance >> etc. > > What about using a relation to add secondary land uses? why? If the landuse is inside another landuse, and not excluded by multipolygon, why use a relation (it is more complicated and breaks easier). What would be the benefit? There is a proposal to do so anyway (site-relation). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Google has dual carriage way where it's not built yet
2009/10/12 Ben Laenen : >> I made a proposal: >> http://wiki.openstreetmap.org/wiki/Key:planned > > > So what's the difference with highway=proposed + proposed=...? > > I can't seem to find the wiki page, but highway=proposed is already in use and > it's rendered in the Mapnik layer. maybe this one? http://wiki.openstreetmap.org/wiki/Proposed_features/Road/Rail_proposed there's also an inactive duplicate here: http://wiki.openstreetmap.org/wiki/Proposed_features/Proposed there's a big difference: my proposal doesn't break rendering for renderers/routers/other consumers that don't know the tag planned, while the linked proposal breaks it by rendering a proposed street like an already built one in case it doesn't know the specific tag! cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/13 Martin Koppenhoefer : > 2009/10/13 John Smith : >>> This does not sound completely strange, but still incorporates some >>> problems (all currently tagged landuse=military will get deprecated). >>> I don't see the big problem here, as you can >>> 1. draw a landuse=military around the whole area (and probably >>> military=barracks) >>> 2. draw a landuse=forest around the actual forest >>> 3. draw a landuse=school around the actual school (or building=school >>> for the school-building) >>> 4. draw and tag the parking_lot where it is. >>> >>> IMHO landuse=military is already what you want to express with >>> boundary=military. The boundary-object can be tagged as >>> barrier=fence/wall/whatever with entrances, gates, videosurveillance >>> etc. >> >> What about using a relation to add secondary land uses? > > why? If the landuse is inside another landuse, and not excluded by > multipolygon, why use a relation (it is more complicated and breaks > easier). What would be the benefit? There is a proposal to do so > anyway (site-relation). I thought the problem was due to a polygon not being able to be used for 2 different landuse=* tags... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Google has dual carriage way where it's not built yet
Martin Koppenhoefer wrote: > 2009/10/12 Ben Laenen : > >> I made a proposal: > >> http://wiki.openstreetmap.org/wiki/Key:planned > > > > So what's the difference with highway=proposed + proposed=...? > > > > I can't seem to find the wiki page, but highway=proposed is already in > > use and it's rendered in the Mapnik layer. > > maybe this one? > http://wiki.openstreetmap.org/wiki/Proposed_features/Road/Rail_proposed no, not this one. > there's also an inactive duplicate here: > http://wiki.openstreetmap.org/wiki/Proposed_features/Proposed More or less. The syntax is just like your proposal, but instead of using "planned", it uses "proposed". So either highway=proposed + proposed=primary/secondary/... or railway=proposed + proposed=rail/tram/... Given that Mapnik is already rendering the highway=proposed syntax, it makes sense to just adjust your proposal to use "proposed" instead of "planned". And you don't really need to go through RFC or voting or whatever, because it's basically documenting established use (osmdoc.com currently gives 200 usages of highway=proposed -- which is actually quite a lot for something which is almost unmappable...). Greetings Ben ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/13 Martin Koppenhoefer > > > This does not sound completely strange, but still incorporates some > problems (all currently tagged landuse=military will get deprecated). > I don't see the big problem here, as you can > 1. draw a landuse=military around the whole area (and probably > military=barracks) > 2. draw a landuse=forest around the actual forest > 3. draw a landuse=school around the actual school (or building=school > for the school-building) > 4. draw and tag the parking_lot where it is. > > IMHO landuse=military is already what you want to express with > boundary=military. The boundary-object can be tagged as > barrier=fence/wall/whatever with entrances, gates, videosurveillance > etc. > I tend to disagree with you. Landuse should be exclusive by definition. As someone pointed out before in a separate message, this is trying to be a work around the fact that to some extent landuse is broken in some cases. We would like to avoid having two super imposed landuse as much as possible. As we get something more and more complex, we will end up with priority rules over landuse which is I believe is not desirable. We could be tagging for the renderer and using layer=*, but that's not an adequate solution, not even close. This particular case is trying to solve the issue that we see in France with military bases with buildings, forest, fields, etc... inside a military base. Anyway some of the comments you are making are making sense but it is just relying on the renderer to get it right. Emilie Laffray ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Visual map for the blind
2009/10/13 : > I would love to agree, but the needs of disabled persons are widely spread > over our tagging scheme anyway, and awareness of objects that refer to > accessibility is nearly zero. > There are categories for visual, hearing and walking impariment, colletcted > in the category "accessibiliy". > > The ":blind" in my proposal as a postfix was an idea to approach what you > recommend. accessibility:blind=* ? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Housenumber interpolation with regularlyskippednumbers
On Mon, Oct 12, 2009 at 10:29 PM, Mike N. wrote: > TIGER obfuscates the data by declaring the entire numbering range of a > zone: for example a "400 block / Even" containing houses 404 through 420 > would be declared as "range Even / 400-498" in TIGER. For navigation > purposes, that gets you to within one block of an address. Maybe they do it for obfuscation, but that has the additional advantage of being able to locate an approximate address when house #422 (or #402) gets added to the block. Of course, we don't have to be quite as dumb as Tiger. We could always use three blocks, 400-404/Even, 404-420/Even, and 420-498/Even. > I have no problem with the relation that Anthony proposes except that it > seems unnecessary to introduce a new construct to represent the same idea. It's not quite the same idea, though. The Karlsruhe Schema maps actual addresses, at the house location. The Tiger Schema (for lack of a better name) maps potential address ranges, at the street location. They both have their uses: If a house is located far away from the actual street, you would certainly want to use something like the Karlsruhe Schema. If you have no idea where the house is (or is going to be) located other than its relation to a street, you would want to use the Tiger Schema. Arbitrarily sticking a way some distance to the right or left of a highway, in order to coax street-level data into a house-level schema, would be inappropriate. And that's just the easy case, when you're not trying to combine data from both schemas on the same block (I'm not sure that any of these have been mapped yet, but imagine a rural area with lots of houses near the road, some houses far off the road in flag lots with long driveways, and some houses both on and off the road in various stages of development and not yet assigned addresses; or try to combine actual addresses and potential addresses on a road in a retail area with lots of strip malls with individually addressed stores; or a road with lots of apartment complexes/condos with individually addressed apartments/condos). > Now imagine if they were asked to check > the address relation: "Go into edit mode, check the way the arrows point on > your street, inspect the left / right roles to be sure that the house > numbering is correct". For clarification, the direction for the purposes of right/left would be determined by the start and end node, not the direction of the way. The way could be reversed without breaking anything (and not all the ways have to even go the same direction). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/13 Martin Koppenhoefer : > IMHO landuse=military is already what you want to express with > boundary=military. Then all the landuse=military tags can be changed, and landuse=military can be deprecated. On the other hand, ownership=military and/or access=military makes more sense than boundary=military. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Housenumber interpolation with regularlyskippednumbers
>> TIGER obfuscates the data by declaring the entire numbering range of a >> zone: for example a "400 block / Even" containing houses 404 through 420 >> would be declared as "range Even / 400-498" in TIGER. For navigation >> purposes, that gets you to within one block of an address. > > Maybe they do it for obfuscation, but that has the additional > advantage of being able to locate an approximate address when house > #422 (or #402) gets added to the block. Of course, we don't have to > be quite as dumb as Tiger. We could always use three blocks, > 400-404/Even, 404-420/Even, and 420-498/Even. Why use 3 blocks?If a cursory survey shows that 404 and 420 are physically the endpoints of a block, why not use a single way? Even if 420 is not the physical endpoint, why not a single way? > It's not quite the same idea, though. The Karlsruhe Schema maps > actual addresses, at the house location. The Tiger Schema (for lack > of a better name) maps potential address ranges, at the street > location. They both have their uses: If a house is located far away > from the actual street, you would certainly want to use something like > the Karlsruhe Schema. If you have no idea where the house is (or is > going to be) located other than its relation to a street, you would > want to use the Tiger Schema. Arbitrarily sticking a way some > distance to the right or left of a highway, in order to coax > street-level data into a house-level schema, would be inappropriate. What is a house number after all, if not street-level data? The house number has no meaning to the physical building if not attached to a street. I still perceive the Tiger Schema as a variation on the Karlsruhe Schema - the only difference is the estimated accuracy. > And that's just the easy case, when you're not trying to combine data > from both schemas on the same block (I'm not sure that any of these > have been mapped yet, but imagine a rural area with lots of houses > near the road, some houses far off the road in flag lots with long > driveways, and some houses both on and off the road in various stages > of development and not yet assigned addresses; or try to combine > actual addresses and potential addresses on a road in a retail area > with lots of strip malls with individually addressed stores; or a road > with lots of apartment complexes/condos with individually addressed > apartments/condos). I would never use the Karlsruhe Schema ways to determine a house/building location. There can be many good reasons to use address interpolation when the building location is unknown - no aerial photographs, blurred or obstructed aerial photos, new construction, etc. >> Now imagine if they were asked to check >> the address relation: "Go into edit mode, check the way the arrows point >> on >> your street, inspect the left / right roles to be sure that the house >> numbering is correct". > > For clarification, the direction for the purposes of right/left would > be determined by the start and end node, not the direction of the way. > The way could be reversed without breaking anything (and not all the > ways have to even go the same direction). Now I'm confused. Unless the street is one-way, the only way to find the start and end node is to go into edit mode. Streets can be oriented in any direction, so left/right is often not useful for physical representation on the map. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Housenumber interpolation with regularlyskippednumbers
On Tue, Oct 13, 2009 at 12:31 PM, Mike N. wrote: >>> TIGER obfuscates the data by declaring the entire numbering range of a >>> zone: for example a "400 block / Even" containing houses 404 through 420 >>> would be declared as "range Even / 400-498" in TIGER. For navigation >>> purposes, that gets you to within one block of an address. >> >> Maybe they do it for obfuscation, but that has the additional >> advantage of being able to locate an approximate address when house >> #422 (or #402) gets added to the block. Of course, we don't have to >> be quite as dumb as Tiger. We could always use three blocks, >> 400-404/Even, 404-420/Even, and 420-498/Even. > > Why use 3 blocks? If a cursory survey shows that 404 and 420 are > physically the endpoints of a block, why not use a single way? Even if 420 > is not the physical endpoint, why not a single way? Because the area from 404 to 420 is unlikely to be 16/98 the size of the area from 400 to 498. > What is a house number after all, if not street-level data? It's generally postal service data, at least in the US (I believe outside the US as well, but I'm not 100% sure). > The house > number has no meaning to the physical building if not attached to a street. When I lived on campus at the University of Massachusetts, my address was "1403 Washington". Washington was not the name of a street, it was the name of the building. Furthermore, even when an address does point to a street, you don't always get to the address by using that street at the closest point of the street to the address (and sometimes, you don't even use that street at all). >> And that's just the easy case, when you're not trying to combine data >> from both schemas on the same block (I'm not sure that any of these >> have been mapped yet, but imagine a rural area with lots of houses >> near the road, some houses far off the road in flag lots with long >> driveways, and some houses both on and off the road in various stages >> of development and not yet assigned addresses; or try to combine >> actual addresses and potential addresses on a road in a retail area >> with lots of strip malls with individually addressed stores; or a road >> with lots of apartment complexes/condos with individually addressed >> apartments/condos). > > I would never use the Karlsruhe Schema ways to determine a house/building > location. There can be many good reasons to use address interpolation when > the building location is unknown - no aerial photographs, blurred or > obstructed aerial photos, new construction, etc. Just because you're using address interpolation doesn't mean you have to use the Karlsruhe Schema, though. If you have no idea where a house is other than it's relative location on a street, you shouldn't use the Karlsruhe Schema. You shouldn't randomly tag locations away from the street, if all you know is a location on the street. >> For clarification, the direction for the purposes of right/left would >> be determined by the start and end node, not the direction of the way. >> The way could be reversed without breaking anything (and not all the >> ways have to even go the same direction). > > Now I'm confused. Unless the street is one-way, the only way to find > the start and end node is to go into edit mode. Streets can be oriented in > any direction, so left/right is often not useful for physical representation > on the map. My suggestion was to use a relation, not to tag the ways directly. Tagging the ways directly wouldn't work - an interpolation might cover more than one way. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Google has dual carriage way where it's not built yet
2009/10/13 Ben Laenen : >> http://wiki.openstreetmap.org/wiki/Proposed_features/Proposed > > More or less. > > The syntax is just like your proposal, but instead of using "planned", it uses > "proposed". I see one big difference though: planned was not just for highways but for any feature. > Given that Mapnik is already rendering the highway=proposed syntax, it makes > sense to just adjust your proposal to use "proposed" instead of "planned". yes, you're right, didn't know that. There is 158 proposed entities in OSMdoc (and just 5 planned). I changed the page, it is now here: http://wiki.openstreetmap.org/wiki/Key:proposed I also moved the discussion. I don't know how to redirect from the old page, please feel free to do so if you are able to. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Housenumber interpolation with regularlyskippednumbers
> Just because you're using address interpolation doesn't mean you have > to use the Karlsruhe Schema, though. If you have no idea where a > house is other than it's relative location on a street, you shouldn't > use the Karlsruhe Schema. You shouldn't randomly tag locations away > from the street, if all you know is a location on the street. I'm still not convinced that the Tiger Schema / Estimated tagging is any different from the Karlsruhe Schema, except for precision - all of which could be resolved by adding level of precision tags to the Karlsruhe Schema. >>> For clarification, the direction for the purposes of right/left would >>> be determined by the start and end node, not the direction of the way. >>> The way could be reversed without breaking anything (and not all the >>> ways have to even go the same direction). >> >> Now I'm confused. Unless the street is one-way, the only way to find >> the start and end node is to go into edit mode. Streets can be oriented >> in >> any direction, so left/right is often not useful for physical >> representation >> on the map. > > My suggestion was to use a relation, not to tag the ways directly. > Tagging the ways directly wouldn't work - an interpolation might cover > more than one way. A relation would work, but would certainly hide addressing details from any untrained community wishing to submit corrections. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Housenumber interpolation with regularlyskippednumbers
actually I think that instead of discussing interpolation with regularlyskipped numbers you could map explicitly the nodes of the real numbers, thus getting a high-precision map instead of this interpolation-crab, that is much less useful then an actual accurate position ;-) just my 2 cents. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [talk-au] How to tag a non-existent road
Ok, so my big question is: Why are your property boundaries rendered with solid fill? Its not indicating land use, and should be rendered as a 'dash-dot-dot-dash' line. (at least thats how i remember it from drafting class) So if the property boundaries arnt filled in, then there is room to go around and tag areas of 'landuse=residential; or farmland or protected_area or industrial or what ever. Its after the area has been tagged with an appropriate landuse tag, that it becomes clear where the roads 'should technically' be, and there is also (I think) a tag landuse=civil (to show that the city owns it) Me hopes that makes sence :) cheers, Sam On 10/13/09, John Smith wrote: > Unless anyone has an objection I propose that we tagged non-existent > roads from DCDB Qld as: > > highway=gazetted_road > > Anything that hasn't been surveyed can be tagged as highway=road which > is consistent with current usage, these will also be rendered enough > to indicate they need to be surveyed and hopefully this will encourage > people to participate even if they don't have a GPS. > > I updated the wiki as well to reflect this: > > http://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#What_about_using_meta_information_from_the_DCDB_Qld_date.3F > > ___ > Talk-au mailing list > talk...@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-au > -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Housenumber interpolation with regularlyskippednumbers
On Tue, Oct 13, 2009 at 5:36 PM, Mike N. wrote: >> Just because you're using address interpolation doesn't mean you have >> to use the Karlsruhe Schema, though. If you have no idea where a >> house is other than it's relative location on a street, you shouldn't >> use the Karlsruhe Schema. You shouldn't randomly tag locations away >> from the street, if all you know is a location on the street. > > I'm still not convinced that the Tiger Schema / Estimated tagging is any > different from the Karlsruhe Schema, except for precision - all of which > could be resolved by adding level of precision tags to the Karlsruhe Schema. I suppose it's possible. You can duplicate the way(s), stick the new way in some random nearby spot, and add a tag which denotes the fact that the way is in a random spot. I can't imagine why you'd want to do that, but you can. Actually, I can imagine why you'd want to do it. It's called tagging for the renderers and the editors. > A relation would work, but would certainly hide addressing details from > any untrained community wishing to submit corrections. We shouldn't jump through convoluted hoops avoiding relations simply because the editors don't yet make relations easy to edit. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [talk-au] How to tag a non-existent road
2009/10/14 Sam Vekemans : > Ok, so my big question is: > Why are your property boundaries rendered with solid fill? > Its not indicating land use, and should be rendered as a > 'dash-dot-dot-dash' line. > (at least thats how i remember it from drafting class) > > So if the property boundaries arnt filled in, then there is room to go > around and tag areas of 'landuse=residential; or farmland or > protected_area or industrial or what ever. > > Its after the area has been tagged with an appropriate landuse tag, > that it becomes clear where the roads 'should technically' be, and > there is also (I think) a tag landuse=civil (to show that the city > owns it) > > Me hopes that makes sence :) It makes sense, but you missed the point entirely. The property boundary landuse is unknown, between the boundaries there are voids, these voids seem to exist where there is road ways and water ways. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Housenumber interpolation with regularlyskippednumbers
>> A relation would work, but would certainly hide addressing details from >> any untrained community wishing to submit corrections. > > We shouldn't jump through convoluted hoops avoiding relations simply > because the editors don't yet make relations easy to edit. It's not just the editors - it's the case of getting the help of more people who can glance at a common map rendering and see that a correction needs to be made. I see from 3 to a dozen new people pop up in the surrounding region when there is a publicity blip - they recognize a road that is misrouted or misnamed, so they sign up and make the correction. Secondly, there are the consumers of OSM data. There is already a defined sequence of steps that must be followed to determine a physical location from a street address. Now add to that a completely separate search and calculation algorithm that operates on different objects and must be coded and tested. It's only code and someone can crank out the code and unit tests, but completely unnecessary since we already have a construct that is well suited when properly qualified. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Housenumber interpolation with regularlyskippednumbers
On Tue, Oct 13, 2009 at 10:28 PM, Mike N. wrote: > >>> A relation would work, but would certainly hide addressing details from >>> any untrained community wishing to submit corrections. >> >> We shouldn't jump through convoluted hoops avoiding relations simply >> because the editors don't yet make relations easy to edit. > > It's not just the editors - it's the case of getting the help of more > people who can glance at a common map rendering and see that a correction > needs to be made. Renderers can render things that are in relations. There's nothing stopping them from doing that. > Secondly, there are the consumers of OSM data. There is already a defined > sequence of steps that must be followed to determine a physical location > from a street address. Now add to that a completely separate search and > calculation algorithm that operates on different objects and must be coded > and tested. It's only code and someone can crank out the code and unit > tests, but completely unnecessary since we already have a construct that is > well suited when properly qualified. Determining a physical location from a street address is trivial using either schema. Geocoding software would simply need to check for the address in the Karlsruhe Schema, then, if and only if it could not find the address there, check for it in the Tiger Schema. It would then return a latitude and longitude plus a flag to indicate which method it used. Putting both forms of data in the same schema would not make this any easier. There still would need to be a check first using the data marked as complete, and then, if and only if that failed, using the data marked as incomplete. The process would be pretty much identical. In fact, it's trivial to convert from the Tiger Schema to the Karlsruhe Schema. Just copy the ways from the relation, combine them into one way, and move them by some arbitrary distance away from the original way. The reverse conversion would be far from trivial. Merely finding the original way(s), which may have moved, been deleted, been renamed, been split, been combined, etc. will be a nightmare, or even impossible. But look, I don't really care that much any more. Do whatever you want. If you want to create millions of ways offset from the highways by some small arbitrary distance, be my guest. As long as it doesn't lose information (and it doesn't seem like it's going to, at least not that much), I'll learn to live with it. And if it does lose information, I'll just maintain my own private database separate from OSM, with the extra information. I've done some tagging of some different methods of tagging strip malls under the current (and slightly extended) Karlsruhe Schema. Unfortunately, Mapnik hasn't gotten around to rendering all the tiles yet, so I'll wait until later to reveal them. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [talk-au] How to tag a non-existent road
On Tue, Oct 13, 2009 at 5:26 PM, John Smith wrote: > 2009/10/14 Sam Vekemans : > > Ok, so my big question is: > > Why are your property boundaries rendered with solid fill? > > Its not indicating land use, and should be rendered as a > > 'dash-dot-dot-dash' line. > > (at least thats how i remember it from drafting class) > > > > So if the property boundaries arnt filled in, then there is room to go > > around and tag areas of 'landuse=residential; or farmland or > > protected_area or industrial or what ever. > > > > Its after the area has been tagged with an appropriate landuse tag, > > that it becomes clear where the roads 'should technically' be, and > > there is also (I think) a tag landuse=civil (to show that the city > > owns it) > > > > Me hopes that makes sence :) > > It makes sense, but you missed the point entirely. > > The property boundary landuse is unknown, between the boundaries there > are voids, these voids seem to exist where there is road ways and > water ways. > eye... i, i ie :0) But of course the landuse us 'unknown' by default. .. so what needs to be done is to go around and find out what the actual landuse is. ... of course there are voids there are voids all over the map of black space. :) When these boundaries are filled in, with 'area=yes' ... then yes there appear to be 'voids' But it's just like a power line running through somewhere you cant automatically say that the land under it is a 'no-go' zone. ... you cant put anything there, until eithor A - you get more data available, or B- it is physically survayed. My point is that you dont need to be drawing in ANY roads your just importing boundaries nothing todo with roads. For examaple... I have polygons that are ready to be imported for landuse=residential. For me, since im aware that roads are being imported, It's silly for me to be importing this landuse=residential polygons... 'cause when you see them (with no roads around) you CAN extrapolate and see that the space between them, is wide enough for a road to be. but it could be a landuse=industrial. So the solution (im doing) is that i make these .osm files available on a server, as the conversion part... and just let these files sit there until someone want them. So for Austrailia... my guess is that YES, the road data will 'most likely' become available in the next year. So why be so concerned about these empty spaces? .. why not just focus the efforts on converting all the other different types of data available, and make those available as .osm files.... and keep the discussion going on 'how to appropriately tag the features that are available' rather than how to tag what is NOT available. and again, If was to go out there and survay an area and i see that there is no road. ... what i DO see is that there is a landuse=something (farmland) (desert) ... or but a fence if there is one. .. or natural=grassland. 'cause there ALWAYS something. .. ditch ... whatever.. Once that area is physically surveyed, it's mapped that i's something. ... and there should be no question. .. from what i see on that sourcedata website, you got LOTS of different datasets available to play with.... i think that the BBQ's have been dealt with, whats next? http://wiki.openstreetmap.org/wiki/Data.australia.gov.au/World_Heritage_Areas? cheers, (fun taking in circles) ... good times, im learning too. Sam :-) p.s. You guys will probably be done your import before Canada's done :) lol... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [talk-au] How to tag a non-existent road
2009/10/14 Sam Vekemans : > But of course the landuse us 'unknown' by default. .. so what needs to be > done is to go around and find out what the actual landuse is. > ... of course there are voids there are voids all over the map of black > space. :) Swing and a miss... The property boundary data looks like this: http://wiki.openstreetmap.org/images/0/0d/Mapserv-wms-example.all-hallows.png The thickish white sections are actually transparent pixels because there is no data in this data set for that area, the most common "things" that fill the void that I've see so far is road ways and water ways. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [talk-au] How to tag a non-existent road
I made another example: http://wiki.openstreetmap.org/images/5/5d/Dcdb-example.png It's clearer in this screen shot (using JOSM, JOSM has a black background so the transparent pixels are black) exactly what runs down the middle of these voids. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [talk-au] How to tag a non-existent road
2009/10/14 John Smith : > http://wiki.openstreetmap.org/images/5/5d/Dcdb-example.png Here's the after shot: http://wiki.openstreetmap.org/images/b/bf/Dcdb-example2.png ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [talk-au] How to tag a non-existent road
Then the yellow must be all the "landuse=residential" then :) As land use can extend past the property boundary, were there is an easment. Strike 3, im out. Since were on the tagging list, the sidewalks & waterworks like sewer lines, or underground cable lines, do we map these too, as the data is also available? Sam On 10/13/09, John Smith wrote: > I made another example: > > http://wiki.openstreetmap.org/images/5/5d/Dcdb-example.png > > It's clearer in this screen shot (using JOSM, JOSM has a black > background so the transparent pixels are black) exactly what runs down > the middle of these voids. > -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [talk-au] How to tag a non-existent road
2009/10/14 Sam Vekemans : > Then the yellow must be all the "landuse=residential" then :) In this instance I'd guess the same thing, but without a survey we won't know for sure. > As land use can extend past the property boundary, were there is an easment. Easements show up as a void also, although a lot of these tend to be lane ways, a lot don't exist, which is why surveys need to be done, but at least this way it might be mathematically possible to come up with a route to cover the most ground with the least amount of fuel. A "single" place can buy out next door, but it might still be considered 2 properties by the relevant governments. http://osm.org/go/ueSlZ561Q- It doesn't render properly (tourism=theme_park), although I filed a bug about it, but according to the DCDB Qld data, the Ginger Factory occupies 2 adjoining properties. > Since were on the tagging list, the sidewalks & waterworks like sewer > lines, or underground cable lines, do we map these too, as the data is > also available? People are already tagging overhead high voltage power lines in areas, although being above ground they can be useful land marks for navigating etc. If you think the data will be useful, or is specifically useful to you, I don't see why not. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
