On Fri, Apr 18, 2008 at 3:14 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi, > > >>> * what if way direction is reversed? > >>> * what if way is extended, merged, split? > >> > >> That will be a problem indeed. Could theoretically be solved with > >> strong editor support, but that does not fix the intrinsic flaw. You > >> never know when a script comes around that reverses direction for > >> some > >> valid reason, outside the editors. Someone on talk-nl suggested > >> using > >> a NSEW-based tagging scheme, but this is not unambiguous either. > > > > I say these problems are irrelevent right now. We have other tags > > (like oneway) which break when roads are reversed and that doesn't > > seem to excite anyone enough to fix it. I'd say ignore that problem, > > when it gets solved for other tags, it'll get solved for these also. > > The oneway tag dos not suffer from splitting a way. Oneway is > displayed on the maps and sometimes in the editors as well so people > will notice when they make mistakes. We'd have to work on giving > house numbering the same prominence on map as oneway arrows if we > want to enable people to spot bugs the same way they do with oneways. > > In another post you say that other GIS systems have no trouble using > a left/right start/end scheme. One has to be careful when making > these comparisons because many many GIS systems out there are > basically read-only, or at least not at all intended for an > environment like ours where changes are made on a massive scale by a > massive amount of non-expert users. Something that works well for > them does not necessarily work well for us. It might, but it doesn't > follow logically. > > Bye > Frederik > Keep in mind that this data will be used by more data consumers than just putting numbers on the map. Geocoding apps and GPS maps need this in a format that's easily parsed. The GIS world uses start-end left-right, and this is what a lot of data consumers need, too (I'm thinking of Garmin GPS maps) but I don't think that's the right way to store it in the database. My suggestion on the relevant wiki page is to use relation to associate a house number (really a street address number) to one node on one or two ways (if the node falls at the junction of two ways which is a continuation of the same street). Because certain output formats require it, we do need to know if the number applies to the left or right and if the scheme is odd, even, both and maybe "none" or "single" (for non-numeric addresses or numbers which are not sequential?). With proper editor support, this is not a big deal, and besides, the map is a Wiki--there will be mistakes, but they can be corrected. There are several advantages to this scheme. The first is that it doesn't break anything if a way is split. Another advantage is that you can easily add numbers at nodes to provide increased resolution if the spacing is irregular and the interpolation gives unsatisfactory results. Regarding gaps in numbers: They shouldn't be shown on the maps, but maybe you could add special tag to a node indicating the start or end of a series. The goal for this scheme is to locate a street address number at a relative distance along a way. We're not trying to drop a bomb on a particular house number using this data (I hope!). Do we really need to be concerned about weird cases where you access an address via a different street? Anyway, I think this is a simple scheme which addresses a lot of concerns. Thoughts? Karl
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
