Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
I'm still getting a handle on the schemas in use for OSM, and noticed that concept of matching address nodes to ways when doing imports. I'm not so sure this will be very functional for floodplain counties or heavy agricultural counties. We have thousands of addresses with no corresponding roads; the roads were wiped out in 1993 but the parcels still remain (and we even get regular 911 calls for those addresses on roads that have not existed for 15 years). Same thing for rural areas; plenty of addresses with no corresponding roads. As a further complication, it is very common for an address to have a completely different jurisdiction from the road, since roads are the main divider for municipal/unincorporated boundaries (and you have a lot of those with 90+ munis in 500 sq miles). Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400 Fax: 314-628-5508 Direct: 314-628-5407 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
On Mon, Nov 16, 2009 at 9:41 AM, Lord-Castillo, Brett blord-casti...@stlouisco.com wrote: I'm still getting a handle on the schemas in use for OSM, and noticed that concept of matching address nodes to ways when doing imports. I'm not so sure this will be very functional for floodplain counties or heavy agricultural counties. We have thousands of addresses with no corresponding roads; the roads were wiped out in 1993 but the parcels still remain (and we even get regular 911 calls for those addresses on roads that have not existed for 15 years). Same thing for rural areas; plenty of addresses with no corresponding roads. Can you give some details (privately if you'd like). I'd like to see what TIGER has in this situation. When you say the roads were wiped out, is it still possible to travel (by vehicle, or otherwise) over the area where the road previously existed? Is there still a right of way over that area? If so, there still should be a way, even if it's just highway=path, smoothness=horrible/very_horrible/impassible. This is an interesting example. Thanks for bringing it to us. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
On 16 Nov 2009, at 7:40 , Anthony wrote: On Mon, Nov 16, 2009 at 9:41 AM, Lord-Castillo, Brett blord-casti...@stlouisco.com wrote: I'm still getting a handle on the schemas in use for OSM, and noticed that concept of matching address nodes to ways when doing imports. I'm not so sure this will be very functional for floodplain counties or heavy agricultural counties. We have thousands of addresses with no corresponding roads; the roads were wiped out in 1993 but the parcels still remain (and we even get regular 911 calls for those addresses on roads that have not existed for 15 years). Same thing for rural areas; plenty of addresses with no corresponding roads. Can you give some details (privately if you'd like). I'd like to see what TIGER has in this situation. When you say the roads were wiped out, is it still possible to travel (by vehicle, or otherwise) over the area where the road previously existed? Is there still a right of way over that area? If so, there still should be a way, even if it's just highway=path, smoothness=horrible/very_horrible/impassible. can send you pics of residential roads in tiger/osm/garmin/google… absolute impassable overgrown. Tiger is full of dead data. Google managed lately to remove railways which don't exist for ages. if an area with dead data was't filled with something new no one will ever fix it because it's impassable. no survey possible, areal images don't help in forests. so it will stay there forever This is an interesting example. Thanks for bringing it to us. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
On Mon, Nov 16, 2009 at 12:07 PM, SteveC st...@asklater.com wrote: On Nov 15, 2009, at 8:23 PM, Anthony wrote: On Sun, Nov 15, 2009 at 10:05 PM, SteveC st...@asklater.com wrote: So you put the house numbers on the nodes and then what happens with them all when you switch the way direction? Nothing. Every editor has to know to reorder the left and right hand numbers? Nope. Up/Forward is defined as the direction in which the numbers go up. I already explained that earlier in the thread. Awesome, and what about if they don't go up in the same direction? If what doesn't go up in the same direction? Can you give an example? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
Dan, What's wrong with doing automated addressing imports in situations where we have point level address data? Or are you just referring to not importing the addressing that is available for the Tiger data? Kate Chapman On Sun, Nov 15, 2009 at 6:00 PM, Dave Hansen d...@sr71.net wrote: On Sun, 2009-11-15 at 14:49 -0800, Dan Putler wrote: The upshot, for a number of US counties you would rather use the county centerline road data rather than TIGER data as the basis of the import. That's really good news. This is exactly what happened for Massachusetts. They had better data, and were willing to get it imported in lieu of TIGER. I think those two things are the key: 1. Data exists in a form that it can be imported 2. There are willing people to do the import If we don't have both of those things, it makes sense to skip doing something like TIGER and use the local data. But, I think just having the data be theoretically available to import should be enough to stop an inferior but available set getting imported. But, I'm not sure we're going to do any truly automated addressing imports in the US, anyway. -- Dave ___ Imports mailing list impo...@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
On Sun, 2009-11-15 at 18:28 -0500, Kate Chapman wrote: Maybe I'm confused about the address versus road information. I would think the address point would be the front door of the building and would not be a relation to the road. So the node of the address and the way of the road would not be on top of each other. You're right, they're not geographically right on top of each other. But, in OSM we have these relation data primitives to tie different thing together. In this case, we use relations to tie addresses and roads together. I think this is in case of things like the road getting moved. The address nodes at least don't become orphans. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
On Sun, 2009-11-15 at 18:54 -0500, Anthony wrote: On Sun, Nov 15, 2009 at 6:17 PM, Dave Hansen d...@sr71.net wrote: On Sun, 2009-11-15 at 18:11 -0500, Kate Chapman wrote: What's wrong with doing automated addressing imports in situations where we have point level address data? The issue is that it may not line up with the roads at all. Well, address locations don't always line up with roads. That's not a bug, that's a feature. Though I suspect you mean something else, and I'm not sure quite what it is. There's nothing wrong with doing point-level address imports. The only thing I would suggest is ensuring that we connect those points ways or whatever to the roads that represent them somehow. One way to do that is relations. They ensure that you can't, for instance, delete the road without also considering how deleting the road might affect addresses on that stretch of road. We also need to ensure that we *find* the roads to which it refers to ensure that we get the relations done properly. There's no need for relations, which I would think you'd be aware of, since you're not using relations with your TIGER address import I'm not done yet. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
On Sun, Nov 15, 2009 at 7:04 PM, Dave Hansen d...@sr71.net wrote: There's nothing wrong with doing point-level address imports. The only thing I would suggest is ensuring that we connect those points ways or whatever to the roads that represent them somehow. 1) Why? 2) Are you planning on doing that with the TIGER address import? One way to do that is relations. Relations could connect the points with ways, but without a whole lot of work they're not going to be able to connect them with roads, because a single road can consist of many different ways. Until some sort of relation is invented to connect multiple ways to a single road, the best way to connect a point with a road is by using the name of that road. Maybe you meant that you wanted to connect the points with ways, but if so it's unclear what connection you would want to make. The best candidate would be to connect the points with the way which is used to get to the point, but that has pretty much nothing to do with addresses - your address may be X Street, but your driveway might be connected to Y Street. Mapping driveways isn't a prerequisite for adding address information, and you wouldn't want to use a relation for that anyway, you'd want to use a way. They ensure that you can't, for instance, delete the road without also considering how deleting the road might affect addresses on that stretch of road. It doesn't, and it shouldn't. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
For a single county or jurisdiction, if you delete the TIGER data and import more accurate local data, what do you do at the boundaries? County/Stare data sets I've seen usually get cut off +/- a few hundred feet (if that) from the boundary. Does somebody go through and make them fit/connect? or just leave them be and eventually they'll get fixed. Listening to the is TIGER harmful talk, I for one am glad TIGER was imported. It's obviously poor quality data and I never use it in my own work. However, it was consistent over geography and attributes for the whole country. Also, there's much less of a barrier to move a road to the right place then to create new ones. Of course, maybe you don't want mappers you don't really understand the OSM scheme. From my own experience, with some data there (TIGER or otherwise), I was able to get OSM noticed by several of my colleagues, even if the data was not great. If there were mostly blank areas, they never would have looked twice. I tend to agree that imports damage the growth of the editor community. However, IMO this one-time import got a whole lot of people to start using OSM in the US. If the goal is to reach the widest possible audience (by that I mean mappers AND users) than the TIGER import was a good idea. If the goal is get the most accurate data, regardless of how long it takes, then the import probably shouldn't have taken place. If the goal is simply to have fun, then it doesn't really matter, just play with what's there. :-) - John Kate Chapman wrote: Dan, Alexandria gave us permission to import their data but still wanted the 100 dollar CD fee. Someone paid that and we do have the data. As far as I know nobody has asked Fairfax County, but I figured making D.C. look nice with a combination of mapping and importing would be a strong tool when asking other jurisdictions for data. After importing the DC data we were going to make a strong push to ask others. One thing we've been trying to do is have residents of those counties/ cities ask about importing data. I live in Loudoun County and have been discussing with them the possibly obtaining their data as well. A lot of local jurisdictions seem interested I think more than anything they just need to be approached in the right way. Kate On Nov 15, 2009, at 6:50 PM, Dan Putler dan.put...@sauder.ubc.ca wrote: Hi Kate, Sounds good. My guess is that the data from the District is based on the assessor parcels. Given what you said (I'm assuming you are in the Northern VA suburbs of DC), have you looked into whether Fairfax County or Alexandria has released their parcel or centerline road data? Dan On Sun, 2009-11-15 at 18:43 -0500, Kate Chapman wrote: Hi Dan, Both manual and donated data. I've been addressing my neighborhood in Virginia but Washington D.C. donated point level addresses. Kate Chapman On Nov 15, 2009, at 6:37 PM, Dan Putler dan.put...@sauder.ubc.ca wrote: Hi Kate, How have the address points been obtained? From OSM users? The Census Bureau has collected and created a national data set of them in preparation for the 2010 Census, but for non-disclosure reasons, they have no intention of releasing them to the public. The next possible public source of this type of information would be based on county assessor parcel data, but that is limited to those counties that have released their parcel data (although, counties that have released address ranged centerline street data also tend to be the same ones who released their parcel data). Dan On Sun, 2009-11-15 at 18:28 -0500, Kate Chapman wrote: Dave, Understood, I would envision it being a partially manual and partially automated process. Maybe I'm confused about the address versus road information. I would think the address point would be the front door of the building and would not be a relation to the road. So the node of the address and the way of the road would not be on top of each other. Is this incorrect? -Kate Chapman On Sun, Nov 15, 2009 at 6:17 PM, Dave Hansen d...@sr71.net wrote: On Sun, 2009-11-15 at 18:11 -0500, Kate Chapman wrote: What's wrong with doing automated addressing imports in situations where we have point level address data? The issue is that it may not line up with the roads at all. We also need to ensure that we *find* the roads to which it refers to ensure that we get the relations done properly. If people find a way to do that, it shouldn't be a problem. Or are you just referring to not importing the addressing that is available for the Tiger data? -- Dave -- Dan Putler Sauder School of Business University of British Columbia -- Dan Putler Sauder School of Business University of British
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
Oops hit reply instead of replying to the mailing list :/ I personally favor having the possible address range in the street way segment (between intersections) Easier to edit and maintain, as well as smaller memory and bandwidth when working with it. Split each intersection, then build relations for the streets. This is more 1 to 1 on the tiger and other GIS source imports as well. One of the problems has been which side is left if the way is reversed. With editor support this might get handled pretty well though. Another option is to use N S E W as the side instead, or as a sanity check in the editor to see if it was messed up. As I understand it the odd/even sides of the street were largely standardized. This also leaves it clearer to do point or polygons for individual addresses. Dale On Sun, Nov 15, 2009 at 7:24 PM, Peter Batty peter.ba...@gmail.com wrote: Hi all, 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. The major concern I have is that if you are moving streets that have associated address ways, you will need to move three (or more) ways instead of just one. If you rename a street and the street name is also in the address ways, you need to rename the address ways too. But moving streets in a manageable way is my main concern. I think there is a lot of merit in considering a simple start and end range stored as attributes on the street (either left and right ranges separately, or just start and end will work in many cases). This is especially suitable where you are looking for a reasonable approximation to an address, as you get with most online mapping systems like Google, MapQuest, etc - which is I would think the most common use case for most applications. If people have the time and inclination to enter precise addresses then that's great and that data should take precedence of course if you find it. But if you don't find a more precise address (a node or an address way) then you fall back to looking at streets and ranges. 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. 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. But I do think there is an argument for the more approximate form using address ranges on streets themselves for TIGER data in particular (where it is likely that we need to do quite a bit of cleanup on the data). If people are creating data from scratch this is also a faster way to get us to a workable geocoding solution for most applications (which is an area where we are further behind the commercial vendors than we are for basic mapping). Cheers, Peter. On Sun, Nov 15, 2009 at 5:04 PM, Dave Hansen d...@sr71.net wrote: On Sun, 2009-11-15 at 18:54 -0500, Anthony wrote: On Sun, Nov 15, 2009 at 6:17 PM, Dave Hansen d...@sr71.net wrote: On Sun, 2009-11-15 at 18:11 -0500, Kate Chapman wrote: What's wrong with doing automated addressing imports in situations where we have point level address data? The issue is that it may not line up with the roads at all. Well, address locations don't always line up with roads. That's not a bug, that's a feature. Though I suspect you mean something else, and I'm not sure quite what it is. There's nothing wrong with doing point-level address imports. The only thing I would suggest is ensuring that we connect those points ways or whatever to the roads that represent them somehow. One way to do that is relations. They ensure that you can't, for instance, delete the road without also considering how deleting the road might affect addresses on that stretch of road. We also need to ensure that we *find* the roads to which it refers to ensure that we get the relations done properly. There's no need for relations, which I would think you'd be aware of, since you're not using relations with your TIGER address import I'm not done yet. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- 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 -- Dale Puch -- Dale Puch
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
On Sun, Nov 15, 2009 at 7:47 PM, Dale Puch dale.p...@gmail.com wrote: Split each intersection, then build relations for the streets. Do you even have to split? Just add a node, and put the house number on the node. One of the problems has been which side is left if the way is reversed. Put the house number on the nodes. Up is the direction in which the numbers go up. Reversing the way then has no effect. :) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
If you have two streets intersecting and put a number on that node, it isn't clear which street that applies to. You could add an artificial node close to the end of the street, but that seems a bit more messy to me. So my gut feel is that the simplest approach is still attributes on the street. You can also fairly easily write some validation checks that would highlight (and fix) many errors (number ranges being repeated, or a range which was reversed). On Sun, Nov 15, 2009 at 6:16 PM, Anthony o...@inbox.org wrote: On Sun, Nov 15, 2009 at 7:47 PM, Dale Puch dale.p...@gmail.com wrote: Split each intersection, then build relations for the streets. Do you even have to split? Just add a node, and put the house number on the node. One of the problems has been which side is left if the way is reversed. Put the house number on the nodes. Up is the direction in which the numbers go up. Reversing the way then has no effect. :) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- 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
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
When I said messy, I guess I was thinking of two things - one is doing the import, as you mention here (which is sort of where the discussion started). This seems quite a bit more complex if you have to split ways and insert nodes. The other is in writing a geocoding engine based on the data which is produced. If you have the data all on the way, it is a simple query to find one record, and you interpolate along the geometry. I'm not sure how you would write an effective geocoding engine directly based on the model with nodes - I think you would need to write some additional that traced the network and created a new data structure similar to what you would have in the case with attributes on the road. So it seems to me simpler to just create and maintain that data structure directly. In terms of how to decide what number you use when you split a way, you have the same problem in either case (whether you have nodes at the beginning and end of the way, or an attribute range). The most obvious approach is to interpolate based on distance, which is what geocoding engines using address ranges do - this would give you the same geocoding results before and after. If you specifically know the street numbers either side of the split then you can enter those instead. Cheers, Peter. On Sun, Nov 15, 2009 at 6:43 PM, Anthony o...@inbox.org wrote: On Sun, Nov 15, 2009 at 8:32 PM, Peter Batty peter.ba...@gmail.com wrote: If you have two streets intersecting and put a number on that node, it isn't clear which street that applies to. You could add an artificial node close to the end of the street, but that seems a bit more messy to me. If you're adding the nodes manually, it's reasonable - you'd want the numbers to start at the place where the house is anyway, not at the intersection. If you're adding things automatically, I guess I have to admit it's a little messy - much less than adding two ways, but yeah, it's a bit artificial (you could always add a second node in the same exact location as the intersection, but only connected to one way, but let's not go there). Alternatively, you could use a relation, to specify which way you're talking about. From a technical standpoint I guess that's better, but people don't like relations. So my gut feel is that the simplest approach is still attributes on the street. How do you split a way? Do you just guess at the address at the point of the split? Isn't that even more messy? -- 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
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
Anthony writes: 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. Peter, I have to challenge you on this. *Some* TIGER data needs quite a bit of cleanup. *Some* TIGER data is already in good shape, and the only fixes needed are 1) joining at county borders and 2) unjoining at bridges. Just for grins, I looked at Ogdensburg, NY. Been there a few dozen times and hadn't done any editing (uploading as I send this). Frankly, I see very little that needs correcting, and all the usual stuff that needs to be added ... which would need to be added without the TIGER data. Like footpaths, buildings, POIs. So yeah, a lot of work above and beyond TIGER. It's not like there's a shortage of improvements. It's ridiculous to claim that the TIGER import has caused anybody to not edit. If it has, then we've failed to explain exactly how wonderful OSM can look when it's fully populated. I signed up for the USA 'conversion team' with the express intention of challenging the use of the Karlsruhe schema. Anthony, what is your design? How is it better than Karlsruhe? Is it in the wiki yet, so the rest of us can see it? -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
Russ, I think you misunderstood my comment. I am in the TIGER import is a good thing camp. But in the areas I have worked in it has needed a fair bit of minor positional cleanup. My point is that in those cases where you need to graphically adjust a street, I don't want to have to edit three or more ways because there are additional address ways on either side of the street. On Sun, Nov 15, 2009 at 8:06 PM, Russ Nelson nel...@crynwr.com wrote: Anthony writes: 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. Peter, I have to challenge you on this. *Some* TIGER data needs quite a bit of cleanup. *Some* TIGER data is already in good shape, and the only fixes needed are 1) joining at county borders and 2) unjoining at bridges. Just for grins, I looked at Ogdensburg, NY. Been there a few dozen times and hadn't done any editing (uploading as I send this). Frankly, I see very little that needs correcting, and all the usual stuff that needs to be added ... which would need to be added without the TIGER data. Like footpaths, buildings, POIs. So yeah, a lot of work above and beyond TIGER. It's not like there's a shortage of improvements. It's ridiculous to claim that the TIGER import has caused anybody to not edit. If it has, then we've failed to explain exactly how wonderful OSM can look when it's fully populated. I signed up for the USA 'conversion team' with the express intention of challenging the use of the Karlsruhe schema. Anthony, what is your design? How is it better than Karlsruhe? Is it in the wiki yet, so the rest of us can see it? -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog -- 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
