I think the Karlsruhe schema is good where you are trying to model addresses pretty precisely and you're not expecting major updates to the street network. But I think with the TIGER data we have a different situation. And like I said, the two aren't incompatible, you can use a simpler approach on the basic TIGER import (however we decide to implement it), and add data in Karlsruhe format if you want to add more precise addresses later.
On Sun, Nov 15, 2009 at 7:40 PM, SteveC <st...@asklater.com> wrote: > I suspect the Karlsruhe schema is a bit like the license change. Everyone > thinks they have a better idea, and it will take 3 weeks of back and forth > to go over it before they figure out that it's the best (or, least worst) > way forward... but by then another 3 people who need convincing pop up.... > then 9 then 27... until you reach the tail off of the s-curve. > > > On Nov 15, 2009, at 5:52 PM, Anthony wrote: > > > On Sun, Nov 15, 2009 at 7:24 PM, Peter Batty <peter.ba...@gmail.com> > wrote: > >> I'm coming a bit late to this debate, but I just wanted to raise a > fairly > >> basic question, which is whether the Karlsruhe schema is the best one to > use > >> in the situation we find ourselves in with TIGER, where quite a bit of > data > >> cleanup is anticipated. > > > > I signed up for the "USA 'conversion team'" with the express intention > > of challenging the use of the Karlsruhe schema. Maybe you can sign up > > too (even if you're not in the US). > > > >> The main challenge with > >> maintaining this format, as Frederik and others pointed out, is if you > split > >> or join a way. But it's relatively easy to put logic in editors to > handle > >> that, and even if you have to do it manually, it seems to me easier to > >> maintain this model than the more precise Karlsruhe schema if you are > doing > >> quite a bit of data cleanup. > > > > The TIGER data has already been significantly degraded from people > > doing just this type of thing. The problem is, if a way goes from 2 > > to 100, and you want to split it in the middle (say, due to a change > > in the number of lanes), you have to either resurvey the addresses or > > take a shot in the dark and split it 2-48, 50-100. That might be > > reasonable if the 2-100 were accurate in the first place, but if that > > 2-100 were really 2-20, you've seriously screwed things up. The TIGER > > data already contains large numbers of instances of exactly this, but > > there's no sense introducing a schema which makes this even worse. > > > > On the other hand, there are other possibilities which avoid this > > problem and also avoid creating multiple ways. Join the conversion > > team with me and we can talk about them. > > > >> So this is not an either / or proposal of course - both forms could > exist, > >> and you search for the more precise form before the more approximate > form. > > > > As much as I hate the meme of saying +1 when you agree with someone, I > > have to say +1. Or maybe "AMEN". > > > > On Sun, Nov 15, 2009 at 7:47 PM, Dale Puch <dale.p...@gmail.com> wrote: > >> I personally favor having the possible address range in the street way > >> segment (between intersections) > > > > Join the team! > > > > Anthony > > > > _______________________________________________ > > Imports mailing list > > impo...@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/imports > > > > Yours &c. > > Steve > > -- Peter Batty - President, Spatial Networking W: +1 303 339 0957 M: +1 720 346 3954 Blog: http://geothought.blogspot.com
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
