On Tue, 2008-12-02 at 22:20 +0000, [EMAIL PROTECTED] wrote > From: Richard Weait <[EMAIL PROTECTED]> > Subject: [Talk-ca] GeoBase import goals > > Things I'd like to see from our collaboration with GeoBase. Some of > these things my be harder than others. But we can't get there if we > don't plan where we are going. I hope that you'll add your thoughts > here and in the wiki. > > NRN added to OSM without clobbering OSM contributions. And in such a > way that future NRN updates are easier to incorporate to OSM than the > original import. > > Geographical names data base. Make generous use of the is_in tag to > help with indexing. > > Canadian boundary data in OSM. There is no reason for Canada to remain > an undifferentiated mass of maple syrup and poutine. Let's have > provincial (etc.) boundaries. > > Hey kid, want a WMS server? GeoBase has aerial imagery for us. In some > places it is higher resolution than current YWMS. If only we had a WMS > server to use it in our editors. >
What will it take to create a WMS server? > Block level addressing in the Karlsruhe style where GeoBase provides > addressing data. > > National hydro network. Include this in OSM. > This is one of the biggest advantages to importing the GeoBase data. We will, eventually, get all of the roads and trails incorporated into OSM without having something like GeoBase but getting the national hydro network would be virtually impossible. It would require accessing too many private properties that it would be impossible. With the GeoBase import we can significantly speed up the importing of roads and trails and can realistically include the national hydro network. > From: Matt Wilkie <[EMAIL PROTECTED]> > Subject: Re: [Talk-ca] Importing geobase data, learning from everyone > > > The issue here is that OSM is a sandbox, where all points get moved, > > changed, added, & ommited (in the case of adding roads that exist > > already). > > The question is: how to deal with the duplicates? And how to deal with > > geobase updates? > Can we give the duplicates, the OSM data that is already there, the attributes of the GeoBase data so that in the future any updates treat the already present OSM features as if they were originally GeoBase data? > From: "Sam Vekemans" <[EMAIL PROTECTED]> > Subject: Re: [Talk-ca] importing GeoBase Data (learning from TIGER) > To: "Steve Singer" <[EMAIL PROTECTED]> > Cc: [email protected] > > Why not draw in boxes where the geobase (large rubber stamp*) wont > happen? -placed to the nearest .125 degree? > > *a stamp because thats what it is like, when a new version is > available, we can let everyone know. Just like when a new satalite > image is made available; > What about the missing data within that box? I work extensively in Hamilton ON and I know that there are areas that are pretty well covered but still have the odd street that is missing. If we exclude those areas that are fairly well mapped (eg Toronto, Montreal, Hamilton, Burlington, Vancouver, Victoria, etc) from the GeoBase import then we are going to be having some areas that are going to have less than optimum coverage. Unfortunately we are going to have to find a way to check every part of this country and that includes those areas that have an extensive amount of mapping already done. And the new data imported from GeoBase is going to have to not clobber that data that is already there and the contributions from those that have already worked on the OSM map. > From: "Sam Vekemans" <[EMAIL PROTECTED]> > Subject: Re: [Talk-ca] importing geobase > I don't really see a purpose of going any deeper than the red lines, > as all the geobase data would be rendered. .. as the map is used as > tracing. ... or maybe there is? > In other words we are not going to really be importing the GeoBase data, it will really only be another WMS layer that is going to have to be edited by people at some point to really be in OSM. We have to really import the data and it has to render in the same way that any data entered by you, myself and anyone else without differentiating where it came from for the casual user. And that data needs to appear when it is entered just as if you, I, or anyone else had entered it through the normal editing of the map. Keeping the GeoBase meta-data on the data that is entered from the GeoBase data is something that can be dealt with behind the scenes and should not impact the rendering of the map. > Until the Geobase data gets imported, i think the best bet is to focus > on providing the GPS Map's showing both the Ibycus Topo, and the OSM > data. .. this way, when people are out there mapping.. they can see > right way, what is missing from both maps, and add it in on OSM. As > we want to try and eliminate (as much as possible) people being > disappointed, by mapping what is going to be imported.) Why? When someone goes out and uses a GPS to navigate an area and uses those GPS tracks to create new ways I say go ahead. If the GeoBase data covers the same area I still trust that there are GPS tracks to show where a way is. We should not be looking for corner cases where the GeoBase data is incomplete or wrong and only map there but rather to encourage people to map as much as possible wherever they want. The more complete the map is the better and since we really do not know when we are going to be incorporating the GeoBase data why not encourage people to continue to do as much as possible. We agree, or so I am assuming, that the data already in OSM when we start to import the GeoBase data is not going to be overwritten and is important. So, due to the hard work of some mappers, there may just be a little less to import from GeoBase when the time comes. > > Just as how Ibycus did, where some lines showed up as railway tracks, > when they were supposed to be power lines. .. or trails listed as > roads etc. I think the way Ibycus did it, was starting with the most > common areas, and getting feedback and working with the comments. > So in this case, it would be those test areas, and making sure > everyone knows about it, ... as it's not very reversible. .. assides > from manually going to an area and selecting, unless it's possable to > search and select only certain tags? > That is really simply a matter of editing. I have corrected errors made by myself and others and others have edited things that I have done. Sometimes it is merely a difference of opinion as to how something should be tagged and at other times, in fact many times, others have added additional tags to the data that I originally imported into OSM and have enhanced its value. If a tag is wrong then it will eventually be corrected, it is one of the advantages to the type of development that exists within OSM, by someone regardless if the original source if the data was from a mapper or from GeoBase or from anywhere else. It is happening in the USA with people correcting and enhancing the TIGER data all the time and it will also happen here in Canada. > From: "Sam Vekemans" <[EMAIL PROTECTED]> > Subject: [Talk-ca] Import .mp into OSM > > Have you given it any thought? ... about say... importing Ibycus tiles > directy to OSM? ... > or is it better to stick with importing it directly from the source? > 'cause Ibycus already did the leg work for it .. and it's from the same > source.??? .. downloading the IMG files, opening them up in GPSMapedit and > saving as MP files. My suggestion in this case go directly from the source. We know that we have the legal permission to use it and that we have access to everything there. There is not the potential of copyright issues or legal access to it that might occur if we use a derived source. Who owns the changes to the original data and are there going to ever be any legal issues to using it in the future? At least with GeoBase that is not going to be a concern, or at least we know that it will effect all of the Geobase derived data within OSM. And at least with GeoBase we have an understanding to the licensing issues and do not have to be afraid that we are adding complications with additional licensing. And Ibycus does have licensing restrictions that we cannot tolerate within OSM (eg non-commercial) and so any data derived from it would taint OSM and prevent it from being used. > From: "Sam Vekemans" <[EMAIL PROTECTED]> > Subject: [Talk-ca] mp2osm updating Wiki page > > If we can agree on where we want to have the bboxes which will exclude 'ALL > GeoBase import' have that box as light as possible, > I dont think it has to be a box, just a full area, so then on the Ibycus mp > file it would just be a matter of selecting all the geobase data that would > be duplicated (1 tile at a time) and deleting the data. so the remainder of > the data which didnt get placed would need to be hand placed. > > So it's really 2 topics of discussion. 1 the technical importing process, > and 2 the size of the areas that need to be protected. > > A thumbtack: Because Ibycus map is now almost a year old, there is more > detailed data available.. ie house numbers for provinces. Do we wait for > Ibycus to produce a whole new mapset? ... or go the otherway and import the > data from each geobase section? > Why use Ibycus? We have the raw source that they have used, and sometimes even newer as well, so why not concentrate on the GeoBase data itself and forget about Ibycus altogether. With the GeoBase data we know we are clear to use it, the legal people have agreed from both OSM and GeoBase, so why not just use the GeoBase data on its own. It is not like the amount of work importing the Ibycus data is going to be significantly less than if we go directly from the GeoBase data. And the Ibycus data is tainted and restrictive in how we can use it, the licensing for the Ibycus derived data is going to have to be respected even after we import it into OSM and so taints the entire OSM project. And as for protecting areas I believe that it is the wrong approach. We are going to have to develop some means to prevent the GeoBase data from wiping out the work already done on the map wither the area is complete, or almost so, or there is a single road in an area. Dealing with a densely populated area that is relatively complete is really not much more difficult than covering a single stretch of highway going though Northern Ontario except that there are just more roads and other details within that densely populated area. Sorry for the long message but there is a lot of discussions that I felt needed to be commented on. Richard Degelder rtdg _______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
