<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;">Hi<br><br>Would it be possible to get the geobase<font style="font-weight: normal;" size="3"> Orthoimage</font> imagery up as and alternative to the Yahoo! Ariel imagery in Potlatch? In many rural areas the 10 metre imagery has significantly better resolution.<br><br>Sam<br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> "talk-ca-request@openstreetmap.org" <talk-ca-request@openstreetmap.org><br><b><span style="font-weight: bold;">To:</span></b> talk-ca@openstreetmap.org<br><b><span style="font-weight: bold;">Sent:</span></b> Monday, February 16, 2009 8:30:57 PM<br><b><span style="font-weight:
bold;">Subject:</span></b> Talk-ca Digest, Vol 12, Issue 10<br></font><br>Send Talk-ca mailing list submissions to<br> <a ymailto="mailto:talk-ca@openstreetmap.org" href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://lists.openstreetmap.org/listinfo/talk-ca" target="_blank">http://lists.openstreetmap.org/listinfo/talk-ca</a><br>or, via email, send a message with subject or body 'help' to<br> <a ymailto="mailto:talk-ca-request@openstreetmap.org" href="mailto:talk-ca-request@openstreetmap.org">talk-ca-request@openstreetmap.org</a><br><br>You can reach the person managing the list at<br> <a ymailto="mailto:talk-ca-owner@openstreetmap.org" href="mailto:talk-ca-owner@openstreetmap.org">talk-ca-owner@openstreetmap.org</a><br><br>When replying, please edit your Subject line so it is more
specific<br>than "Re: Contents of Talk-ca digest..."<br><br><br>Today's Topics:<br><br> 1. CanVec /geobase NIDs (Sam Vekemans)<br> 2. Re: OSM Geobase import: giving a try (Frank Steggink)<br> 3. OSM GeoBase import: giving a try (Richard Degelder)<br> 4. Re: OSM Geobase import: giving a try (Steve Singer)<br> 5. Re: GeoBase Wiki edits (Steve Singer)<br> 6. Re: GeoBase Wiki edits (Sam Vekemans)<br> 7. Automatch for importing NHD (Sam Vekemans)<br> 8. Re: OSM Geobase import: giving a try (Frank Steggink)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 15 Feb 2009 13:44:06 -0800<br>From: Sam Vekemans <<a ymailto="mailto:acrosscanadatrails@gmail.com" href="mailto:acrosscanadatrails@gmail.com">acrosscanadatrails@gmail.com</a>><br>Subject: [Talk-ca] CanVec /geobase NIDs<br>To: <a ymailto="mailto:steggink@steggink.org"
href="mailto:steggink@steggink.org">steggink@steggink.org</a>, <a ymailto="mailto:talk-ca@openstreetmap.org" href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a><br>Message-ID:<br> <<a ymailto="mailto:9dbbf3b20902151344k4741f45fk1b346be3a5f837cb@mail.gmail.com" href="mailto:9dbbf3b20902151344k4741f45fk1b346be3a5f837cb@mail.gmail.com">9dbbf3b20902151344k4741f45fk1b346be3a5f837cb@mail.gmail.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>Hi,<br>welcome to the team! I look forward to seeing the progress on the 021L07 area.<br><br>Your questions were already answered, and thank you, as it gives me a<br>better idea of how to make the wiki more clear :)<br><br>re: nids<br>i brought up the issue again as it needs to be further explained on<br>the wiki, (with respect to CanVec also) as there is always 2 sides to<br>decisions. -notion of 'expectancy' needs to be adressed in 1 page or<br>less, and clearly
understood.<br><br>I am more in favor of using the 'automatch' for ALL map features.<br><br>Does anyone know that the python script line that adds the OSM tags<br>from the Database file.<br><br>Hopefully someone can help?<br>Trial & error is the other method :)<br><br>cheers,<br>Sam<br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Sun, 15 Feb 2009 18:05:48 -0500<br>From: Frank Steggink <<a ymailto="mailto:steggink@steggink.org" href="mailto:steggink@steggink.org">steggink@steggink.org</a>><br>Subject: Re: [Talk-ca] OSM Geobase import: giving a try<br>To: Steve Singer <<a ymailto="mailto:ssinger_pg@sympatico.ca" href="mailto:ssinger_pg@sympatico.ca">ssinger_pg@sympatico.ca</a>><br>Cc: <a ymailto="mailto:talk-ca@openstreetmap.org" href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a><br>Message-ID: <<a ymailto="mailto:49989FCC.803@steggink.org"
href="mailto:49989FCC.803@steggink.org">49989FCC.803@steggink.org</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Hi Steve,<br><br>Thanks for your response.<br><br>> Yes the wiki needs a cleanup, I've been hoping someone else would do it <br>> since that doesn't seem to be happening I will try to find sometime soon <br>> to delete all obsolete information from the wiki pages.<br>I'll try to do some cleanup, once I have a better understanding of th eefforts <br>of others.<br><br>> Yes please try to keep nids for data that actually comes from geobase.<br>> Not importing could limit us in the future.<br>In what way would it limit us? When we'll receive a new dataset from Geobase? Or <br>do you hint towards other datasets which are linked to the NID? In that case <br>that additional data can't be linked to existing database, because that doesn't <br>contain the NID attributes.<br><br>>> b. How
can we guarantee that the final import will be consistent? <br>>> (See also<br>>> my first question.)<br>> <br>> Depends what you mean by consitent.<br>> 1. Using consistent tags for things, the best way to ensure this is to <br>> look at what others are doing and share your scripts.<br>> <br>> 2. data consistency, ie roads line up and are joined between different <br>> imports or between the existing and geobase data. Right now we have no <br>> automated consistency tools, we are depending on people to manually line <br>> up/connect ways post import.<br>Both meanings were intended. I wonder if automatic consistency will work. It <br>seems to have a too high chance of failure.<br><br>> You are free to use your own processes and software. I don't think any <br>> two people are doing the exact same thing for importing. This is the <br>> process I follow<br>> <br>> You don't need to
use roadmatcher, you just need to have some method of <br>> avoiding hundreds of duplicate roads.<br>I actually wanted to use PostgreSQL/PostGIS, but it seems that no OSM data can <br>be exported from it. At least not when OSM data was previously imported through <br>osm2pgsql. Maybe it will work to keep the Geobase data in Postgis, export as <br>OSM, and then apply some postprocessing (fixing in JOSM).<br><br>> For comparision purposes what I've done with the larger areas in Alberta:<br>> <br>> 1. Populate a postgis database with the NRN shapefile<br>> 2. Populate a postgis database with the OSM data using osm2pgsql<br>> 3. Generate a NRN and OSM shapefile for the area that I'm interested in<br>> using pgsql2shp and some SQL queries. I handle reprojection during this<br>> process as well (lately I've been reprojecting into meters)<br>> 4. Import both shapefiles into jump and automatch with roadmatcher<br>> 5. Export my
results<br>> 6. Run geobase2osm on the NRN GML file(yes I had to download the NRN data<br>> twice) and produce a standalone file<br>> 7. Review the standalone file in JOSM<br>> 8. Upload the standalone file with bulk_upload.pl<br>> 9. Manual fixup in JOSM.<br>I'm going to try to generate buffers around the imported road data from OSM, and <br>will use it to clip away any Geobase data (NRN) which is entirely within a <br>certain distance from the OSM data. And then export it to OSM. I'll need to work <br>it out further, using my test area. I think that a buffer of 10 or 20 meter is <br>enough.<br><br>> Do not use any of the Ibycus stuff the import the licenses are not <br>> compatible. Do not use ibycus in the geobase import. Someone should <br>> have removed these references from the wiki a long time ago. I will try <br>> to do it soon.<br>OK. Makes sense to me. It's already postprocessed to some degree, rendering
it <br>less suitable.<br><br>> I just viewed/posted my initial .osm files in JOSM and when people where <br>> happy with them I did an import to a small isolated area. Using a <br>> seperate userid is a good idea.<br>> <br>> You can get the latest version of geobase2osm.py here, a number of <br>> people have used this as the basis for their custom procedures.<br>> <br>> <a href="http://svn.openstreetmap.org/applications/utils/import/geobase2osm/geobase2osm.py" target="_blank">http://svn.openstreetmap.org/applications/utils/import/geobase2osm/geobase2osm.py</a> <br>OK, will give that a try :) But it might be necessary if I use PostGIS as the <br>main repository for the Geobase data. I want to remove the number of steps as <br>much as possible, to make it more automatable and user friendly.<br><br>One final question: what is the accuracy of the Geobase data? Is it worse, <br>comparable, or better than typical GPS tracks? The
roads I've drawn so far match <br>the Yahoo imagery quite well, although usually there is a slight offset of a few <br>meters.<br><br>Regards,<br><br>Frank<br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Sun, 15 Feb 2009 20:13:42 -0500<br>From: Richard Degelder <<a ymailto="mailto:rtdegelder@gmail.com" href="mailto:rtdegelder@gmail.com">rtdegelder@gmail.com</a>><br>Subject: [Talk-ca] OSM GeoBase import: giving a try<br>To: Talk-CA OpenStreetMap <<a ymailto="mailto:talk-ca@openstreetmap.org" href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a>><br>Message-ID: <1234746822.6475.43.camel@nomad><br>Content-Type: text/plain<br><br>Frank,<br><br>Welcome to the project.<br><br>> Yes please try to keep nids for data that actually comes from geobase.<br>> Not importing could limit us in the future.<br>In what way would it limit us? When we'll receive a new dataset from Geobase? Or <br>do you hint
towards other datasets which are linked to the NID? In that case <br>that additional data can't be linked to existing database, because that doesn't <br>contain the NID attributes.<br><br><br>The reason for keeping the NIDs intact is with any future updates and imports coming<br>from GeoBase, and apparently GeoGratis and CanVac. For OSM itself this data is<br>meaningless, the renderers have no idea how to deal with it and so ignore it. Other<br>imports are going to, unless they have the same NIDs, also not use the data.<br><br>GeoBase regularly does updates to the data sets and are looking to complete the current<br>data sets for all provinces. Their reference value is the NID. As long as we <br>also ensure that the NID is present we are going to be able to easily incorporate those<br>updates when they appear.<br> <br>>> b. How can we guarantee that the final import will be consistent? <br>>> (See
also<br>>> my first question.)<br>> <br>> Depends what you mean by consitent.<br>> 1. Using consistent tags for things, the best way to ensure this is to <br>> look at what others are doing and share your scripts.<br>> <br>> 2. data consistency, ie roads line up and are joined between different <br>> imports or between the existing and geobase data. Right now we have no <br>> automated consistency tools, we are depending on people to manually line <br>> up/connect ways post import.<br>Both meanings were intended. I wonder if automatic consistency will work. It <br>seems to have a too high chance of failure.<br><br><br>Canada is too big, and there is too much data to incorporate everything manually. If we<br>automate as much as possible the more effectively we can incorporate the available data<br>as quickly as possible. The problem is finding an effective way to automate as much<br>as possible without
having too many errors incorporated. Not everything that we are going<br>to want is going to be available from GeoBase, and, in many areas where we have a number<br>of mappers, we are also able to incorporate data before it is available from GeoBase, or<br>even available to GeoBase.<br><br>What we are currently having to do is to have people actually look at the data to clean<br>it up after an import. If we can eliminate that to a large degree, possibly through some<br>form of automation, we can speed up the import process. But until we get to that point<br>we are going to have to have manual intervention. To some degree, however, there is <br>always going to be the times where someone will edit, and modify, data currently within<br>OSM and that is part of the process.<br><br><br><br><br>One final question: what is the accuracy of the Geobase data? Is it worse, <br>comparable, or better than typical GPS tracks? The roads I've
drawn so far match <br>the Yahoo imagery quite well, although usually there is a slight offset of a few <br>meters.<br><br>I have been looking at a lot of the data produced for me by Steve and comparing it to<br>the Yahoo! imagery. I have also found an offset, although it seems to be variable and<br>inconsistent. The GeoBase data comes from a number of sources, each with their own<br>accuracy. Looking at the data it almost seems that the people that entered it have a <br>real influence into the quality. I have found some minor curves marked with a lot of<br>data points while in other cases a more significant bend is marked with only a few. But<br>then the same occurs within OSM and can also be credited to the style of the contributor.<br><br>As for the overall quality of the data from GeoBase I am happy to incorporate it within<br>OSM, it is certainly better than a lot I have seen, including from GPS traces. But
it<br>does depend on the source of the data and the effort of OSM users, when setting up for <br>GPS tracks, can get close enough to the overall quality to match much of it. If you are <br>very careful when creating your GPS tracks, and have a good signal and good equipment, <br>you are going to exceed the quality of some of the GeoBase data but in some cases you are<br>only going to match it with your best efforts.<br><br>Have fun importing the data. And if you can develop a best practises that can import the<br>effectively and accurately, hopefully without overwriting the current OSM data, then<br>let others know so that we all can incorporate those techniques. We are learning as we<br>go and most of us are very willing to learn a better method of being able to import, and<br>use, the tremendous quantity of data that we have available to us with GeoBase.<br><br>We were fortunate to have access to the data and now we are going to have
to find a way<br>effectively assimilate it within OSM. There are going to be minor issues but hopefully<br>we can manage them easily enough. <br><br><br>Richard Degelder<br><br><br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Sun, 15 Feb 2009 20:19:52 -0500 (EST)<br>From: Steve Singer <<a ymailto="mailto:ssinger_pg@sympatico.ca" href="mailto:ssinger_pg@sympatico.ca">ssinger_pg@sympatico.ca</a>><br>Subject: Re: [Talk-ca] OSM Geobase import: giving a try<br>To: Frank Steggink <<a ymailto="mailto:steggink@steggink.org" href="mailto:steggink@steggink.org">steggink@steggink.org</a>><br>Cc: <a ymailto="mailto:talk-ca@openstreetmap.org" href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a><br>Message-ID: <<a ymailto="mailto:BLU0-SMTP69DF86541737E3343502AAACB70@phx.gbl"
href="mailto:BLU0-SMTP69DF86541737E3343502AAACB70@phx.gbl">BLU0-SMTP69DF86541737E3343502AAACB70@phx.gbl</a>><br>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed<br><br>On Sun, 15 Feb 2009, Frank Steggink wrote:<br><br>> Hi Steve,<br>><br>> In what way would it limit us? When we'll receive a new dataset from Geobase? <br>> Or do you hint towards other datasets which are linked to the NID? In that <br>> case that additional data can't be linked to existing database, because that <br>> doesn't contain the NID attributes.<br><br>Mostly when we receive geobase updates.<br><br>Consider what should happen when as geobase releases road name data for <br>provinces that have already been imported. We will just need a script that <br>finds the OSM way that is tagged with a particular geobase:uuid and add in <br>the name tags from the geobase update. If we don't have the uuid in the OSM <br>data we'd need to figure out some
other method.<br><br>Also we think about what happens when a road crosses two of the artificial <br>tiles we dividing the import process across, if each road as a unique NRN <br>id you can easily excluded the nids already imported in the adjacent tile <br>from the current one.<br><br>I only reason to not include it would be to save a few bytes of space.<br><br><br>> I actually wanted to use PostgreSQL/PostGIS, but it seems that no OSM data <br>> can be exported from it. At least not when OSM data was previously imported <br>> through osm2pgsql. Maybe it will work to keep the Geobase data in Postgis, <br>> export as OSM, and then apply some postprocessing (fixing in JOSM).<br><br>I've been exporting OSM data from PostGIS without issues.<br>I've added some more detailed steps at <br><a href="http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature"
target="_blank">http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature</a><br><br>I export the OSM data from PostGIS as a shapefile, I only use this as an <br>input to road matcher (I only need a few fields). I don't think the data<br>from osm2pgsql can be used to regenerate .osm files though.<br><br>> I'm going to try to generate buffers around the imported road data from OSM, <br>> and will use it to clip away any Geobase data (NRN) which is entirely within <br>> a certain distance from the OSM data. And then export it to OSM. I'll need to <br>> work it out further, using my test area. I think that a buffer of 10 or 20 <br>> meter is enough.<br><br>I thought about using buffers initially but then I came across road matcher.<br><br>10-20 meters tends to work for OSM data from GPS traces but the roads from <br>low-res imagery (often of highways in rural areas) often can be off by 100 meters.<br><br>> One final question:
what is the accuracy of the Geobase data? Is it worse, <br>> comparable, or better than typical GPS tracks? The roads I've drawn so far <br>> match the Yahoo imagery quite well, although usually there is a slight offset <br>> of a few meters.<br><br>The Geobase data comes from different sources. Some of it is from GPS, <br>other data is from Vector files and some from imagery. My guess is that all <br>of it is more accurate than the low-res pictures Yahoo provides in Northern <br>Alberta.<br><br>My guess is that most of the geobase GPS data is better/comparable to the <br>typical OSM mapper GPS data, the vector data doesn't seem to be as good (and <br>I've found instances in Ontario where the geobase vector data shows <br>roads/intersections that don't exist). The geobase documentation lists <br>accuracy/precision somewhere but I can't recall what they claim.<br><br><br><br>><br>> Regards,<br>><br>>
Frank<br>><br><br>Steve<br><br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Sun, 15 Feb 2009 20:32:11 -0500 (EST)<br>From: Steve Singer <<a ymailto="mailto:ssinger_pg@sympatico.ca" href="mailto:ssinger_pg@sympatico.ca">ssinger_pg@sympatico.ca</a>><br>Subject: Re: [Talk-ca] GeoBase Wiki edits<br>To: Sam Vekemans <<a ymailto="mailto:acrosscanadatrails@gmail.com" href="mailto:acrosscanadatrails@gmail.com">acrosscanadatrails@gmail.com</a>><br>Cc: <a ymailto="mailto:talk-ca@openstreetmap.org" href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a><br>Message-ID: <<a ymailto="mailto:BLU0-SMTP56D0ED0FB9190A53CF8858ACB70@phx.gbl" href="mailto:BLU0-SMTP56D0ED0FB9190A53CF8858ACB70@phx.gbl">BLU0-SMTP56D0ED0FB9190A53CF8858ACB70@phx.gbl</a>><br>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed<br><br>On Sun, 15 Feb 2009, Sam Vekemans wrote:<br><br>> Hi, great job on editing the page, thanks
:)<br>> Wondering if you think it's a good idea if i make a page [[CanVec]] - to<br>> clearly describe what it is,<br>> and then another page [[CanVec Import]] to show the status.<br>> .. then on the [[Canada]] page, show the status of the whole import.<br><br>I would leave CanVec_OSM_Map_Features page as a top-level page for the <br>CanVec data. That should describe what it is, if the status gets <br>complicated/complete enough you could move it onto a separate page but I <br>don't think we are at that stage yet.<br><br>> Perhaps a chart with CanVec/GeoBase/Other at the top, then The provinces<br>> along the side?<br><br>The main GeoBase import page lists 9 different datasets and we have 13 <br>provinces/territories. I wiki chart with 9 columns seems like it will be a <br>bit hard to read. I don't think you can condense all of the 8 geobase <br>datasets to 1 column since the imports will happen
independently.<br><br><br><br>> Cheers,<br>> Sam<br>><br><br>Steve<br><br><br><br>------------------------------<br><br>Message: 6<br>Date: Sun, 15 Feb 2009 20:47:24 -0800<br>From: Sam Vekemans <<a ymailto="mailto:acrosscanadatrails@gmail.com" href="mailto:acrosscanadatrails@gmail.com">acrosscanadatrails@gmail.com</a>><br>Subject: Re: [Talk-ca] GeoBase Wiki edits<br>To: Steve Singer <<a ymailto="mailto:ssinger_pg@sympatico.ca" href="mailto:ssinger_pg@sympatico.ca">ssinger_pg@sympatico.ca</a>><br>Cc: <a ymailto="mailto:talk-ca@openstreetmap.org" href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a><br>Message-ID:<br> <<a ymailto="mailto:9dbbf3b20902152047s1f9fdc72m6953179901cd655e@mail.gmail.com" href="mailto:9dbbf3b20902152047s1f9fdc72m6953179901cd655e@mail.gmail.com">9dbbf3b20902152047s1f9fdc72m6953179901cd655e@mail.gmail.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>That
makes sence, then i guess its just the wording at the top of the<br>page (canvec map features) that needs to be fixed.<br><br>When i have my script in sharable form & get those charts done -it should help.<br>i'll add a 'who's working on it section' as that might make it more clear.<br><br>Cheers,<br>Sam<br><br>On 2/15/09, Steve Singer <<a ymailto="mailto:ssinger_pg@sympatico.ca" href="mailto:ssinger_pg@sympatico.ca">ssinger_pg@sympatico.ca</a>> wrote:<br>> On Sun, 15 Feb 2009, Sam Vekemans wrote:<br>><br>>> Hi, great job on editing the page, thanks :)<br>>> Wondering if you think it's a good idea if i make a page [[CanVec]] - to<br>>> clearly describe what it is,<br>>> and then another page [[CanVec Import]] to show the status.<br>>> .. then on the [[Canada]] page, show the status of the whole import.<br>><br>> I would leave CanVec_OSM_Map_Features page as a top-level page for the<br>> CanVec
data. That should describe what it is, if the status gets<br>> complicated/complete enough you could move it onto a separate page but I<br>> don't think we are at that stage yet.<br>><br>>> Perhaps a chart with CanVec/GeoBase/Other at the top, then The provinces<br>>> along the side?<br>><br>> The main GeoBase import page lists 9 different datasets and we have 13<br>> provinces/territories. I wiki chart with 9 columns seems like it will be a<br>> bit hard to read. I don't think you can condense all of the 8 geobase<br>> datasets to 1 column since the imports will happen independently.<br>><br>><br>><br>>> Cheers,<br>>> Sam<br>>><br>><br>> Steve<br>><br><br><br><br>------------------------------<br><br>Message: 7<br>Date: Mon, 16 Feb 2009 18:18:56 -0800<br>From: Sam Vekemans <<a ymailto="mailto:acrosscanadatrails@gmail.com"
href="mailto:acrosscanadatrails@gmail.com">acrosscanadatrails@gmail.com</a>><br>Subject: [Talk-ca] Automatch for importing NHD<br>To: <a ymailto="mailto:Talk-us@openstreetmap.org" href="mailto:Talk-us@openstreetmap.org">Talk-us@openstreetmap.org</a>, Ian Dees <<a ymailto="mailto:ian.dees@gmail.com" href="mailto:ian.dees@gmail.com">ian.dees@gmail.com</a>>,<br> <a ymailto="mailto:talk-ca@openstreetmap.org" href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a>, Michel Gilbert <<a ymailto="mailto:michcasa@gmail.com" href="mailto:michcasa@gmail.com">michcasa@gmail.com</a>>, Steve<br> Singer <<a ymailto="mailto:ssinger_pg@sympatico.ca" href="mailto:ssinger_pg@sympatico.ca">ssinger_pg@sympatico.ca</a>><br>Message-ID:<br> <<a ymailto="mailto:9dbbf3b20902161818u38da3cds5e911dd993164274@mail.gmail.com"
href="mailto:9dbbf3b20902161818u38da3cds5e911dd993164274@mail.gmail.com">9dbbf3b20902161818u38da3cds5e911dd993164274@mail.gmail.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>Hi,<br>fyi, the automatch script for importing canada's NRN datasets is<br>available to copy from - hopefully it can help. (to deal with<br>duplicates)<br><br>I still havent figured out how to get the .txt file that converts the<br>database file to osm tags. -the shp2osm script.<br><br>Thanks,<br>Sam<br><br>ps hopefully the talk-ca can learn from the talk-us list.<br><br><br><br>------------------------------<br><br>Message: 8<br>Date: Mon, 16 Feb 2009 21:31:32 -0500<br>From: Frank Steggink <<a ymailto="mailto:steggink@steggink.org" href="mailto:steggink@steggink.org">steggink@steggink.org</a>><br>Subject: Re: [Talk-ca] OSM Geobase import: giving a try<br>To: <a ymailto="mailto:talk-ca@openstreetmap.org"
href="mailto:talk-ca@openstreetmap.org">talk-ca@openstreetmap.org</a><br>Message-ID: <<a ymailto="mailto:499A2184.1080709@steggink.org" href="mailto:499A2184.1080709@steggink.org">499A2184.1080709@steggink.org</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Hi Richard, Sam, Steve,<br><br>Thanks for your feedback. I'll continue using PostGIS (good for my own skills as <br>well), and look at the other suggestions you've made. I'll also leave the NIDs <br>on the data which I will eventually upload. They don't hurt, although there is <br>the theoretical possibility that due to subsequent edits they get shifted <br>(splitting and joining).<br><br>I'll also investigate PostGIS buffering a bit more. 10 to 20 meters should be <br>enough. In cases of roads which have been shifted 100 meters, they need better <br>investigation anyways. In case they turn out to be drawn from low-res imagery, <br>they can better be replaced by the
Geobase data. Hopefully the buffering won't <br>cause data to be removed accidentally. For areas where the OSM density is quite <br>small (as in my test areas) it is no big deal to remove duplicate Geobase roads <br>manually. Better to be safe than sorry. How would RoadMatcher deal with a case <br>where two roads are aligned, but one of them has been shifted?<br><br>With regard of this I also think a manual step should always take place. (Maybe <br>even to evaluate discarded data.) We must only make sure that it covers those <br>parts which can't be done automatically, so the required amount of time spent of <br>it is as small as possible. Our brains can still make judgments better than the <br>computer. I don't think anyone has very sophisticated algorithms which eliminate <br>human input in the process ;)<br><br>I hope to really start with the Geobase import soon. I came across the Global <br>Administrative Areas (GADM) database, which is part of the
BioGeo project <br>mentioned at the potential datasources. I've looked more closely at the data, <br>and exchanged some ideas about the import of this data as administrative <br>boundaries with the guys on #osm-nl. (Sorry, sometimes it's necessary to chat in <br>my mother language ;)) I also inquired after use of the data by OSM, because of <br>their copyright (CC-BY-NC-SA 3.0), and because they aggregated data from various <br>other sources.<br><br>Regards,<br><br>Frank<br><br><br><br>------------------------------<br><br>_______________________________________________<br>Talk-ca mailing list<br><a ymailto="mailto:Talk-ca@openstreetmap.org" href="mailto:Talk-ca@openstreetmap.org">Talk-ca@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/listinfo/talk-ca" target="_blank">http://lists.openstreetmap.org/listinfo/talk-ca</a><br><br><br>End of Talk-ca Digest, Vol 12, Issue 10<br>***************************************<br></div></div></div><br>
<hr size=1>Now with a new friend-happy design! Try the new <a href="http://ca.beta.messenger.yahoo.com/"><b>Yahoo! Canada Messenger</b></a></body></html>