2008/12/6 Sam Vekemans <[EMAIL PROTECTED]> > Ok, cool :) Lots of great discussion points.Again, I'll try > to summarize with this info, and hopefully setting somethings as a > foundation. (in story form) > > Basic questions: > > What do we want to accomplish with the OpenStreetMap project? > and > What do we want to accomplish from Geobase? > > Here's IMO plus adding in everyone else's views (to the best of my > ability) > > By adding features that we are not likely to be able add the map ourselves, > we can import GeoBase data. > > IF the prime purpose IS to complete the road network across Canada, then > in doing so this will cause issues. This is because, technically > speaking. The GeoBase road database IS ALREADY the complete road network > across Canada. Period. With future updates, this database, will ALWAYS be > the complete road and official road network for Canada. It's a federally > funded database, with the goal of being the complete network. > So .. no matter how we twist and turn it, it will still be complete. > > Soo... However, if the prime purpose is to create a totally free and > editable map of the world, we must then treat GeoBase with the same level of > indifference that we do to user:Acrosscanadatrails. Just so happens that > there will be a few users who are importing the data, and have spent a real > long time gathering tracks and points, and converting the points into ways, > and labeling them, and is ready to start bringing in the data. > > Just as user:Acrosscanadatrails did, when he started; He didn't know how > this whole thing worked, and so he started adding in roads. .. and just had > it as highway=secondary, and highway=road for those ways that he didn't now. > ... then he found out that having it as a secondary road, didn't quite match > what similar roads where in other towns, he changed it to > highway=residential, then someone else came along and changed the name from > James St. to James Street and HWY 4 to highway 4. > > So the point is; Is that we can go ahead and start the import, working at > it 1 tile at a time. And just learn as we go along. (use the chart and the > talk list to keep the discussion going) > > (i use User:Acrosscanadatrails as the example for me importing geobase > data) > > So for the areas where User:Acrosscanadatrails did alot of gps tracks and > ways, and converted them to ways and points, and has it all sitting waiting > for the import. Sadly :( the work he did was for nothing. :( as he found > out that a whole mapping team was just in the area and did it all already. > So user:Acrosscanadatrails, doesn't need to complain about it, as after > all, the GPS Tracks he did, DID get imported to the back-end database. ... > and all his points and ways he made got put aside and into the PostGIS > database, as after-all, he did take time to write the house numbers down. > But these numbers just need to be converted to a point along side the road > in the center of where the house is, or real close or converted to a square, > where the 1 side is right on the road. .... but anyways.. after > all no renderer's can read his hand writing from his note paper (BTW, I do > have bad hand writing :) ..) but he was smart enough to keep track of his > own numbers, so these numbers are listed with each point and way he made. > > > So after a while, when user:Acrosscanadatrails started to import roads; he > called them 'freeways' instead of 'moterways'. ... perhaps because > he's stubborn? and doesn't want to change his ways? ... > well fortunately Python script came along to help him translate and speak > OSM language. So the next tile import does the conversion already. > > Fortunatly, user:Acrosscanadatrails still keeps the cross reference number > he originally started with. So now user:Bikecanada comes along and imports > more data. and imports it slightly different, and tags it differently. .. > but thats ok, because other users will come along and fix it to how it > should be. > > So now user:Acrosscanadatrails went around a year later and added in more > roads (not thinking if any thing has been added) and goes around and just > takes note of all the new subdivisions that came up. Well, he'll just to > what he did before... upload his traces to the database, and upload his > points and ways he made to the PostGIS database. But this time, the script > which converts his previous imports is tweaked so it's much much smarter. > ... However, because he knows where his reference points where, he can only > add on extra features that would not be added on otherwise. So... he needs > to only add in the house numbers, and not add in the actual road. (or he can > add in the road class/surface, but only if it hasn't been done) As he knows > that there are other users who are around, and have already drawn in > cycleways, schools, parks in detail. as well as the local roads. > > All of the roads that have been drawn in by hand, are well within the same > degree of accuracy (10 meters) as the roads that User:Acrosscanadatrails has > ready to upload, but he will be let down, :( as not only are his roads just > as good in accuracy, but the other users have actual GPS traces, to varify > the accuracy. So all the user:Acrosscanadatrails can do to help is, add > in the Geodedic survay markers, and hope for better luck next time. > > **** > > So here's the moral of the story: > GeoBase data importance: > 1- the basic level is that contains unnamed lines > 2- the lines have names but no road class > 3- the lines have names, road class and house number > The GeoBase data, is just as smart as a new user, who needs to learn how to > import data and have it tagged so it conforms to OSM standards. The > GeoBase doesn't have special privileges, and no longer 'Owns' the data that > it imports. Anyone can edit it, and choose to not accept it. ... the only > special thing that GeoBase has, is that it has reference numbers, and that > the data was imported into the PostGIS database (which is available only > behind the scenes, and contains both databases) > The technical aspect of the PostGIS database, isn't as important as > importing the data directly, it only becomes useful when it needs to figure > out what Geobase data is useful, so it can spit out only the good stuff. > > So if these are the basic principles that we all can agreed to, we can move > forward to the next step of actual importing. > > IMO, i would think it would be wise to weight a little longer, and hear > from other users, and what is the opinion of the rest of the OSM community, > or at least more interested people. so they get a chance to say something > too. >
I need some clarification about the parallel database (PostGIS). I am sure I see the whole picture of the Geobase Import process. Who is going to host the change tracking PostGIS database ? How are we going to access it ? I prefer a process model that uses only osm database. I don't see how we are going to maintain the PostGis database for users that access Potlatch or JOSM. May be I have not understood the concept yet. > > We can then move on to the next step of actual import. > > I propose that we start with tile 092F04 (Tofino, BC) as thats what i did, > and probably needs the basic script to get the road class right. > Or maybe 082E14 (Kelowna, BC) > or maybe the 030M04 (Hamilton, Stoney Creek, Ontario) but there is alot of > OSM coverage, so i think it would make sense to work with less OSM coverage > areas 1st... so to tweak the import script 1st. and to see what it's like > for fixing GeoBase data to conform with OSM standards. > ... or even 001K10 & 001K11? (south of Saint Johns NFLD) and importing all > the kinds of data available for it? > BC is a good place to work. Geobase data in BC has street and place name. NFLD has not had names yet. Did we figure out the development platform ? The basic script to map the road classes are written to work with JOSM ? or could it be something else. I work with FME (Safe Software) a canadian company in BC. It is a great ETL (Extract,Transform,Load) application. I know it is a commercial product but it could help for the task we have. FME read osm and PostGIS formats and offers many tools to find change detections and manipulate attributes and geometry. FME has a large community, may be even among osm. It could be interesting to find out. > > > And the last thought. ... > re: Ibycus topo > That was added as it's a convenient stop-gap measure, which helps, as there > is a very high probability that all the types of data that was imported to > make that map will show on OpenStreetMap eventually, as well as more data, > and even better data. > Once the actual import starts, i think it would make sense for people to be > downloading the map of the completed area, so to view it, and try to > understand all the kinds of data which is planned to be imported. > and i'm sure everyone knows that the stuff on his map CAN'T be imported > directly, and wont. .. as that doesn't make sense to do so. (perhaps it > need to be written a bit clearer?) > > Cheers, > Sam Vekemans > Across Canada Trails > Michel > > ---------- Forwarded message ---------- > From: Richard Degelder <[EMAIL PROTECTED]> > Date: Fri, Dec 5, 2008 at 4:32 PM > Subject: Re: GeoBase PostGIS & OpenStreetMap > To: Sam Vekemans <[EMAIL PROTECTED]> > > > On Fri, 2008-12-05 at 15:25 -0800, Sam Vekemans wrote: > > Thanks, > > I also got 2 comments about the french name tagging, so i added it to > > the http://wiki.openstreetmap.org/wiki/Talk:GeoBase_Import page. > > And tried my best to translate this talk about PostGIS. :) > > Please edit, if you can :) > > > > The part about the stressing the importance of not undermining OSM > > contributions, needs to be highlighted more. IMO > > > > I looked at the wiki page and also at the map of Southern Ontario that > it pointed to as an example. When I tried to display it the map was > offset from the general landforms, the map was a little south of the > representation of Lake Ontario and Lake Erie, but several things came to > mind immediately. The first was "man do I ever want the import to work > and work soon." There is a lot of detail in there that I want to have > in the OSM map as soon as possible. There is also going to be some > reconfiguring of some of the roads. There are roads with different > designations within the GeoBase map than I know they are rendered within > OSM. But that is a minor technical detail that is really only a matter > of editing at some point. The other impression was there are definitely > areas where OSM is way ahead of GeoBase and includes features that are > not available yet within the GeoBase data. Yes I want to have GeoBase > assed to OSM but I also know that for some newer roads OSM is way ahead > of everyone else including GeoBase, Google maps, Yahoo! maps, and > everyone else. > > >From what I have seen with the example I would love to have the area > around the western end of Lake Ontario imported soon with the knowledge > that there is going to have to be some cleanup done but that it looks > good and allows me to add some additional features to the area as well. > > and > > "Even if there is a single road > > through an area there has to be a way to for us to match it within > > both > > OSM and GeoBase. " > > By using the charts we already started, and the name tags... we can > > create the set of rules that the PostGIS database import script will > > follow. GeoBase Tag = OSM tag. .. and get as detailed as possable. > > > > My prime reference is not going to be GeoBase, although it is certainly > an attempt to import the GeoBase data, but rather OSM. We are > augmenting the current data within OSM with additional data from > GeoBase. Regard GeoBase as a new contributor to OSM, just as you and I > each were at one time. The whole project does not suddenly revolve > around a new contributor but they are allowed to augment, and that > includes editing and even deleting data, the data already within OSM. > GeoBase is just a new contributor that needs our help to edit the map > and to improve things within Canada. Maybe GeoBase has an overwhelming > amount of knowledge at its disposal but it must conform to OSM rather > than OSM catering to it. Sure, where there is the ability for the > GeoBase tags to augment the current tags within OSM for the data then > add the relevant tags. And among those additions will be the GeoBase id > # for future references. But where the tags conflict then we should go > with the OSM tags. For one thing I am hoping that the OSM tags are > there because someone was on the ground there and saw the reason for the > tag before considering adding it. Of course the person may not have > understood exactly what he or she was looking at and there are always > going to be discussions as how exactly to tag a feature, not that some > alternatives are necessarily wrong but what is the best way to do it. > > > The realtime aspect (my last point on the talk) is still a little > > vague. > > > > Cheers, > > Sam > > At this point we need to understand what the different people are > looking for the GeoBase import to accomplish. For me it is to add > features to the OSM map that I am not likely to be able to do otherwise, > things like the hydro survey which would require me to access a lot of > private properties to do the survey. If the prime purpose is to > complete the road network across Canada and doing so will cause issues > within OSM to accomplish that then I would recommend we abandon GeoBase > since we will eventually add all of the roads within Canada; it might > take a long time but it is doable with what we have available to us now. > > By discussing what we want from the GeoBase import and how to go about > doing it at this point we can have a clearer understanding about what is > important and even if going forward is really worth it for the project. > And because GeoBase has so much detail we need to pick and choose what > we want to use for OSM. And, within reason, the more we talk about it > the more likely we are to get it right as well. > > Also I would recommend that you downplay any reference to Ibycus since > it is not going to be usable within OSM due to licensing issues since > they do not allow commercial usage of their maps. With OSM we do not > have those restrictions and so importing data form Ibycus in any way, > even if indirectly, may eventually cause issues within OSM. The dame > issues arise with people referring to Google maps as a source of data > for OSM, Google Maps has not given us permission, and licensed it, to > access their maps or satellite data for OSM. > > Richard Degelder > rtdg > > > > > > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca > >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
