Re: [Talk-us] [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
On Nov 14, 2009, at 11:16 AM, Dave Hansen wrote: What really needs to be done for TIGER addresses import is match the streets from TIGER to those in OSM (which should be easy since they all still have the TIGER id's) and generate the address geometry based on these. Otherwise someone will need to do all of the geometry corrections that people have done for this data in the last nearly 2 years. I agree that this is the optimal thing to do. But it's really hard, so I'm not volunteering to take it on. If there's anyone out there braver than I, please speak up. :) I hear you but for the purposes of just thinking about it... I think it might be a lot easier than we think. Forget matching TIGER IDs... if I know a line segment goes from 15th Valencia to 16th Valencia in TIGER then all I need to find in the same set of points in the OSM dataset which isn't going to be super hard. I find 15th, I find Valencia, see if they cross at some node. Same with the other intersection, then see if those nodes are on a way that joins both of them and find the points in between. And as long as the geometry isn't radically different then I can match up the points. I think the major problem would be divided highways where one way is now two ways with different directions, but that shouldn't be super hard to do. Yours c. Steve ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Karlruhe Scheme addressing ways from 2009 TIGER data
On Sat, Nov 14, 2009 at 12:22 PM, Anthony o...@inbox.org wrote: See http://wiki.openstreetmap.org/wiki/Image:Qgis.png for an example of something I whipped up for my neighborhood in a few hours http://api06.dev.openstreetmap.org/api/0.6/changeset/1825/download for a sample of what the osm looks like. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Super Wal-Mart Tag
Matthias Julius wrote: Yes, I would create a relation for each thing in the building having the building itself (area, node or relation) as the only member. That way the different shops (or banks, law offices, dentists, ...) in the building can be independant objects and reference the building. Matthias As far as a mall or strip shopping center, or other building that is not corporately related to the users is concerned (which fits your example, but not Theo's), there's no question in my mind that the shops/amenities should be labeled with separate nodes, and related to the building. However, the majority of the amenities/shops in a Super Walmart are not independent objects but very much a part of Walmart. I don't think I would create a building way, named Walmart, and a separate node named Walmart for each department or department cluster (department store, supermarket, automotive repair, etc.), but would add those tags to the building way itself, and only add nodes for the shops that are identifiably different from Walmart but have contracted to share the Walmart building space. They truly have separate corporate identities, with a relation to the building, rather than being an integral part of the corporation owning/leasing the whole building. I'm not sure that either way is more correct, either method can be parsed. Certainly different people would have different preferences, just as people have different preferences as far as using semi-colons vs. key suffixes to indicate multiple entities within a parent entity. I reserve the right to change my mind on the latter issue, but my current preference is to use semicolons, unless a particular shop/amenity needs further qualification. Then, I'd break it out as shop_1=shop_type, shop_1:quality=quality_value. Again, either of these should be (and I think already is) parseable. Of course, if I were actually mapping the building interior, or whether the automotive repair shop was on the left or right end of the building, then that is a different story, and, again, I believe, out of context to the original question. -- Randy ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] TIGER considered harmful
Dave Hansen wrote: If we can come up with a scheme for getting the addressing imported in a sane fashion and the consensus is that people want it done that way, it'll get imported. There are still quite a few squeaky wheels that like to grumble about TIGER, but I haven't heard a single person say that it did more harm than good. I firmly believe this. TIGER contains so many errors in Oregon, Washington and Idaho that it would likely be easier to start fresh than fix. 1) TIGER data is so out of date for urban parts of Cascadia as to be rendered entirely useless. 2) The TIGER import violates one of the most basic principals of OSM: Abbreviations: DO NOT DO IT. 3) Gotta love how TIGER randomly decides some routes aren't freeways when they actually are (and have been for decades). Washington State has literally thousands of miles of expressway and freeway TIGER got wrong. The TIGER import should never have been done. I wonder how easy it would be to undo this until an actually suitable data source can be found, since the Fed is doing it on wet bar napkins with cartographers who wear hockey helmets and ride the short bus to work. Might as well photograph a turd and call it aerial photography of central Idaho for the accuracy of TIGER...heck, that photo might actually agree with the TIGER data better! ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Super Wal-Mart Tag
Matthias Julius wrote: I consider numbered tags to be messy. Nodes inside the building is not better unless you are really producing a map of the building's internals. How do you figure? Strip malls typically only have one building but all ammeneties are accessable from the outside. And most people find it handy to know where they're going inside a larger facility even if the nodes are only relative (ie, the Subway is inside the WalMart between the Wells Fargo and the nail salon). Some strip malls and older WalMart locations, as well as most Fred Meyer locations are frequently legally subdivided as well: There are tax lots within the building itself! ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Super Wal-Mart Tag - apology
Paul Johnson wrote: Matthias Julius wrote: I consider numbered tags to be messy. Nodes inside the building is not better unless you are really producing a map of the building's internals. How do you figure? Strip malls typically only have one building but all ammeneties are accessable from the outside. And most people find it handy to know where they're going inside a larger facility even if the nodes are only relative (ie, the Subway is inside the WalMart between the Wells Fargo and the nail salon). Some strip malls and older WalMart locations, as well as most Fred Meyer locations are frequently legally subdivided as well: There are tax lots within the building itself! Oops. My apologies, Paul. I was to short, and you were not responding to my post. -- Randy ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
Paul Johnson wrote: Dave Hansen wrote: If we can come up with a scheme for getting the addressing imported in a sane fashion and the consensus is that people want it done that way, it'll get imported. There are still quite a few squeaky wheels that like to grumble about TIGER, but I haven't heard a single person say that it did more harm than good. I firmly believe this. TIGER contains so many errors in Oregon, Washington and Idaho that it would likely be easier to start fresh than fix. 1) TIGER data is so out of date for urban parts of Cascadia as to be rendered entirely useless. 2) The TIGER import violates one of the most basic principals of OSM: Abbreviations: DO NOT DO IT. 3) Gotta love how TIGER randomly decides some routes aren't freeways when they actually are (and have been for decades). Washington State has literally thousands of miles of expressway and freeway TIGER got wrong. The TIGER import should never have been done. I wonder how easy it would be to undo this until an actually suitable data source can be found, since the Fed is doing it on wet bar napkins with cartographers who wear hockey helmets and ride the short bus to work. Might as well photograph a turd and call it aerial photography of central Idaho for the accuracy of TIGER...heck, that photo might actually agree with the TIGER data better! Your mileage may vary. -- Randy ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
On Sun, 2009-11-15 at 10:59 -0800, Paul Johnson wrote: Dave Hansen wrote: If we can come up with a scheme for getting the addressing imported in a sane fashion and the consensus is that people want it done that way, it'll get imported. There are still quite a few squeaky wheels that like to grumble about TIGER, but I haven't heard a single person say that it did more harm than good. I firmly believe this. TIGER contains so many errors in Oregon, Washington and Idaho that it would likely be easier to start fresh than fix. Just curious, but why weren't you mapping when Oregon and Washington were blank? I'm also curious how you've made so many changes. Have you surveyed it, or are you using TIGER plus Yahoo! imagery? What would you have done without TIGER in these cases? 1) TIGER data is so out of date for urban parts of Cascadia as to be rendered entirely useless. Hmm. I live in urban Cascadia. My subdivision was off by ~100m and had a major street routed wrong. I still don't consider it quite entirely useless. Personally, I find it a lot easier to map with GPS traces, my memory and hints from TIGER than to go out and take detailed notes. It looks to me like you do the same thing, so I'm really surprised that you don't like TIGER. 2) The TIGER import violates one of the most basic principals of OSM: Abbreviations: DO NOT DO IT. I thought the basic principles were to have fun and not copy from other maps. :) 3) Gotta love how TIGER randomly decides some routes aren't freeways when they actually are (and have been for decades). Washington State has literally thousands of miles of expressway and freeway TIGER got wrong. This one might be my fault. There are a bunch of TIGER-OSM feature code mappings, and it's quite possible that I just plain got them wrong in some cases, or that we disagree on how the mappings should have been done. If this is still widespread, I'd be happy to look into it to see what can be done to fix it up. BTW, did you go and survey these thousands of miles of roads to ensure that they really are what you think they are? Are you also saying that you'd rather have a blank space in the map than a wrongly-tagged expressway? The TIGER import should never have been done. I wonder how easy it would be to undo this until an actually suitable data source can be found, since the Fed is doing it on wet bar napkins with cartographers who wear hockey helmets and ride the short bus to work. Might as well photograph a turd and call it aerial photography of central Idaho for the accuracy of TIGER...heck, that photo might actually agree with the TIGER data better! So, what I did initially was go and contact all of the mappers in the US that I could find. I asked them all individually what should be done in their local areas and I believe I was able to follow their wishes without failure. If you want to do the same with TIGER removal, I'd welcome it, especially if you have something superior to contribute. On a small or large scale, we should *NEVER* keep any data in the map just because it is what was already there. TIGER doesn't provide the best possible map, but it did (and does) provide the best map that we have access to. If anyone has better suggestions, I'm open to them. Perhaps I have low standard, but I'd prefer a map of turds to whitespace. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Karlruhe Scheme addressing ways from 2009 TIGER data
Hi, Dave Hansen wrote: There are still quite a few squeaky wheels that like to grumble about TIGER, but I haven't heard a single person say that it did more harm than good. Well then you obviously haven't read the two latest entries in Matt Amos' blog here, http://www.asklater.com/matt/wordpress/ (Imports and the Community, parts I and II), with part II ending thus: In conclusion; ... the theoretical model still predicts that imports damage the growth of the editor community. ... Of course Matt's findings are not backed up by a lot of evidence as he himself says, so they might be wrong. And even if they were right, it would be valid (if slightly un-OSM-like) to say to hell with the editor community, I want data now. As long as imports are done in a clean way technically, I don't have a strong opinion in the matter; I strongly believe in everyone taking responsibility for their patch, so if you guys on the other side of the Atlantic decide that you want to import the lot then that's what you should do. Bye Frederik ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Karlruhe Scheme addressing ways from 2009 TIGER data
On Sun, 2009-11-15 at 23:30 +0100, Frederik Ramm wrote: Dave Hansen wrote: There are still quite a few squeaky wheels that like to grumble about TIGER, but I haven't heard a single person say that it did more harm than good. Well then you obviously haven't read the two latest entries in Matt Amos' blog here, http://www.asklater.com/matt/wordpress/ (Imports and the Community, parts I and II), with part II ending thus: In conclusion; ... the theoretical model still predicts that imports damage the growth of the editor community. ... Of course Matt's findings are not backed up by a lot of evidence as he himself says, so they might be wrong. And even if they were right, it would be valid (if slightly un-OSM-like) to say to hell with the editor community, I want data now. That's a really cool set of data, very well thought out. It's also interesting to see that the difference in completeness is less than ~5% no matter how much you import to begin. So, you could read it as, imports don't damage the end result of the map... much :) I have a feeling it's all in the noise anyway. My only nit would be that it misses a very important metric: how prolific were the mappers? I know, before my local area got imported, I did a few streets here and there, but only as much as I could survey and note by hand. Now, I can just take GPS traces and make sure that things line up as cab other people from across the globe. So, instead of unique users per time period, it might be interesting to see unique users*nr_edits per time period. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
On Sun, 2009-11-15 at 14:25 -0800, Sam Vekemans wrote: 1 - A few people (we can call the data conversion team) are in charge of taking the data in it's source form (in this case SHP) We use the tools availble (shp-to-osm.jar and/or shp2osm.py) and are the ones who create a set of 'rules' listed showing the source tags, and how we identify them in OSM. 2 - This team then works and converts this data to OSM format, and makes the files available on a server somewhere. 2a - IF there is alot of conflect then a postProcess is needed. So geobase2osm was created so that we can take an area and use AutoMATCH and see what data needs to be added to osm. 3 - When these .osm files become available on a server, it's up to the local area mappers to decide on what they want todo with the data. 3a - if the data is too complicated, local area mappers tell the conversion team, and this team works out the bugs and learns from everyone else on how to handle it. Yeah, and that does sound like a really nice way to do it, especially when there is existing data. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
On Sun, 2009-11-15 at 14:33 -0800, Dave Hansen wrote: Yeah, and that does sound like a really nice way to do it, especially when there is existing data. Anybody want to be on the USA conversion team? :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] TIGER considered harmful
On Sun, Nov 15, 2009 at 5:36 PM, Dave Hansen d...@sr71.net wrote: On Sun, 2009-11-15 at 14:33 -0800, Dave Hansen wrote: Yeah, and that does sound like a really nice way to do it, especially when there is existing data. Anybody want to be on the USA conversion team? :) Absolutely. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Talk-ca] TIGER considered harmful
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 ___ 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] Whole-US Garmin Map Update
On Sun, Nov 15, 2009 at 6:45 PM, Dave Hansen d...@sr71.net wrote: I updated my whole-US map for Garmin devices. Just take the gmapsupp.img file from here: http://daveh.dev.openstreetmap.org/garmin/ and put in the /garmin/ directory on your device (if you have an SD card unit). Thanks for this, Dave. Good stuff. ___ 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] Karlruhe Scheme addressing ways from 2009 TIGER data
Alan Millar wrote: no one is interested to cleanup crap after a bad import. I am. tiger import was great from technical point of view but didn't allow to build a community from scratch. I didn't want to build anything from scratch. I'm simply not that motivated to go out and wander everywhere mapping everything. If we had to start from scratch, I would not do it. no one is motivated to fix this broken data. I am. I have fixed a lot of it. And in doing so, I have made complete, correct map areas, much larger than I ever would have done by starting from scratch. absolutely, and my critics wasn't so much about tiger import, Dave did a great job and at that time the map was empty. the bigger problem are the other imports which didn't check what data is available already and simply uploaded data because they know how to convert a shape file to osm format. Be careful about making absolute generalized statements like "everyone" and "no one". will add an sarcasm tag in the future... osm should be fun and whatever anyone is saying is just an opinion. - Alan ___ 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] Whole-US Garmin Map Update
On 11/15/09 6:45 PM, Dave Hansen wrote: and put in the /garmin/ directory on your device (if you have an SD card unit). I'll be updating these periodically as I feel the need. I think I also have my methods down to a point where I could just script it and make these weekly or something, if anyone is interested. do you want reports on observed problems? i note that the way data seems very incomplete in the Albany, NY area. but then, i don't know what's really supposed to be in these maps. richard ___ 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
Re: [Talk-us] Whole-US Garmin Map Update
On Sun, 2009-11-15 at 21:17 -0500, Richard Welty wrote: On 11/15/09 6:45 PM, Dave Hansen wrote: and put in the /garmin/ directory on your device (if you have an SD card unit). I'll be updating these periodically as I feel the need. I think I also have my methods down to a point where I could just script it and make these weekly or something, if anyone is interested. do you want reports on observed problems? i note that the way data seems very incomplete in the Albany, NY area. but then, i don't know what's really supposed to be in these maps. Is there OSM data in the area to begin with? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
