[Talk-ca] GeoBase Node Import idea ver 1.0

Sun Dec 28 02:55:54 GMT 2008

Sam, as our first results from Austrian Import all regions, where only nodes
arriveed after import had very much problems - there was many hand made work
with questionable quality. We are now trying to get everywhere the whole
ways in. We put them in a separte namespace so taht renderers do not see
them and local maqppers have the choice to merge them or drop them. That
seems the best concept for us.

greetings from Vienna, Austria

Wolfgang

 Hi there,
  After some serious review, (writing a hudge essays about the answer to the
question.  What do you want to get from GeoBase? (Answer: a better free wiki
map showing more of  Canada) and Why Import GeoBase to openstreetmap?
(Answer: because it will make the map better)
  I came up with new questions and an idea.

  Question 1:
  From looking at the entire GeoBase/CanVec collection, which is held in
Sherbrook.  Is this data stored in a form where the Images/Shapes/Lines are
all available a nodes. .. a point in space?
  So for the images, 4 nodes representing that image cover area.
  For shapes, all the nodes representing the polygon, which has a relation
together so the interface shows it as a shape.
  For the lines, it contains a series of nodes.
  If yes, then this should be true.
  Each node would have all the attributes which GeoBase needs to make the
datasets, and to provide the WMS feed, and provide different types of data
that you make available for all the different usergroups that GeoBase has.

  Question 2:
  Out of the CanVec collection which also has NID's, for
Images/Shapes/Iines, these are also made up of a series of relations, so it
knows that point A,B,C & D are all part of the polygon that make up this
area... this area is labled.
  Then, looking at each node individually, your software that you use to
extract this data, needs to know the exact coordinates of the node, and how
it relates to eachother.   Is that right?

  Here's the Idea:

  We import to OpenStreetMap the full NRCan/GeoBase/CanVec database.. not as
shapes/ways/and lines.. but just as nodes.. and do not connect these nodes.

  We essentially import a Canada Node dump into OpenStreetMap, which shows
all of the attributes that the nodes have. .. making sure to include:

  -NID

  -the name in English/French

  -the object type that NRCan uses.

  -the date at which the data was collected.

  -accuracy of the node

  -maybe the GPS coordinates

  ... and everything else that is relevant and included on the node. (and
everything else which is needed for GeoBase/CanVec/NRCan 's use)

  -and the date at which it was imported into OSM (is already on there)

  -and who imported it.. is already on there

  Then after the "Great Canadian – Node Dump Party".. we relax. And know
that updates to GeoBase/CanVec/NRCan will be made available sometime.. and
shown as more nodes to be added.

  Then after that..

  For those areas which contain no OSM data.. we can go ahead and import all
the data as shape file/ways/lines/points.. and make up a possible OSM
relation that it could be, we can fix the import script so then it would
show it better (closer to what it should be). ... but don't really need to
be that picky. (covering up the lonely nodes) ... it's kind of random... as
thats whats made for the Ibycus topo map.. it's a match-up which is
estimated, as a best guess. ... at least it shows up as the right colour and
line type.. so when your looking at it on the Garmin.. its looks good. ...
even though the ocean is listed as a lake. .. it's still blue...
type=water.. as everything in the NHN thats a shape file.. and everything
that is just a line can be a listed as a river. .. go for basics.

  ...

  The OpenStreetMap project is this:

  'The Free Wiki World map'...

  It doesn't have to show exactly what GeoBase/NRCan says is there. ... this
is why the nodes are imported... the nodes show all the technical details
that GeoBase/NRCan/CanVec needs.

  When an update is available... we only import the new node dataset... and
have the latest date attached as another tag. .. (it would anyway, but its
important to have in planted in there, along with the source name)

  So for those areas which contain more data than GeoBase/CanVec (NRCan)
has... all that will be made available is the nodes. .. so at all the
intersections, there will be a point put in there.. and so, it would be up
to the OSM Mappers discretion if they want to move the existing road-node on
top of this node.. or leave it the way it is. .. the mappers can use those
nodes as a 'guide' .. but not the 'rule' ... after all- we make up our own
rules, and debate about it :) ... probably agree to import everything BUT
the roads in many cases. :)

  These nodes will not be recognized by any renderer.. accept the GeoBase
renderer, but it pulls the data from the feed. .. the real purpose these
serve is to tell users that the road is 'officially-official' at that mark.
... as 'official-official maps are drawn from these nodes'... (and to use as
a reference for OSM Mappers)

  (.. i would recommend importing all the different datasets from the
different sources, and also importing the nodes from the source. .. so when
the road numbers become available, they just show up as nodes... and wont
effect the ways at all... as its a reference tool, as a program can be
created to sort out all that stuff)

  (this way, government agencies are free to extract the specific tags out
of the planet.osm file and should only get the NRCan data.) .. and make
their own maps. ... and use OSM created stuff if they like. (cloudmade does
show a file showing all the highway=* tags that are currently available)

  For most map users, weather or not the lines are 10 meters accurate or .5
meters accurate. ...

  oh ya... Accuracy needs to be added if it isn't already a property of the
NRCan -Canada dump node set.... ... remembering the discussion about
accuracy vs. precision. If the nodes are already in the System, ya.. it's up
to the user how many nodes they want to use. ... just like how many GPS
track points you want to refer to when drawing a straight road.

  And so... for those areas in which contain 1 OSM 'thing', that particular
user should be able to decide if they would like to import all of it, or
just certain features.

  ...

  Then for the roads.. it would be a giant 'Connect-the-dots game'. ..

  ... it's a Wiki decision, so it would make sense that the road data would
be the most sensitave area.. so for those tiles that are half mapped. ..
these mapper would need help in, and those areas that have only 1 road. ..
it would be worth it, to go ahead and import, rather than connect-the-dots.

  If these dots can ALSO be made available as a Plugin layer... WMS layer,
we can see were these nodes have been moved (for reference, if needed)

  Pylons:

  Think of it this way:

  We have 1 billion pylons scattered all over Canada :)

  every pylon was placed there from Government of Canada. these are place
holders, meant to tell GeoBase what exists at that point and how it relates
to all the pylons around it. GeoBase keeps track of all the pylons, and all
the information that is written on the pylon is legible by anyone. .. but
some of it is just code.. and only needed for surveyors. ... but its all
their and useful.

  All the different users out there can choose to use OpenStreetMap, when
there working.. and simply double check to make sure that people didn't move
the pylons, ... but most of the time... we trust each other, that these
pylons were placed at this spot on purpose. :)

  And ya... pylons can be placed on top of each other.. where we know the
latest pylon is on top

  JOSM might just 'squawk' at it. .. but there should be a way to look at
each. .. anyway, the pylons are only to look at, and use if people want to
use them.

  I hope that this makes sense.

  We can explore it further please :)

  Have a wonderful day,

  Sam Vekemans

  Across Canada Trails

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20081228/37dd14e4/attachment.html>