[Talk-ca] OpenAerialMap for geoBase Data? Yahoo! Image 2006 i-cubed?

Sam Vekemans acrosscanadatrails at gmail.com
Thu Jul 24 21:30:05 BST 2008

Since there is such a large amount of data to be processed, wouldn't a
Canadian university be willing and able to host it? ... by now im sure that
all universities are aware of this OSM project.
(as i assume it because even in that state of pre-rendering the data needs
to be stored somewhere)  .. ie. i just added in a road to cultus lake PP..
the road gets saved onto a database.. so it sits in line to be rendered.
However, the information is freely available when anyone else click on
edit.it all, just storing it.
.. so were not talking rendering of road data. as its rendering it
slowely,.. as each user adds in the roads which are accurate.

A preference would be to keep it in that of pre-reneirding, so then the
inconsistancies get manually chanaged. .. A program that could automatically
do that to a whole province? awesome!. ... (storing the data on opentopomap)
.. wouldnt it just be like an extra set of GPX traces when you flip on the
'show gps traces'..
that is.. for the road data?

Then for the topo data ... looking at the cycle map's topo data.
What if a Canadian university could hold the Canadian Digital Elevation
Data, and have that shown as the tiles instead of what is there? I think
this data is more accurate than whats currently shown? ... rather than
creating a new layer (every country would need to have a new layer). ..

So.. in summery.. I sugest to import all the road data as the step after GPX
traces and before it gets rendered.. and make sure the OSM does NOT render
any of the Geobase road data, so it just sits on the database (a
universities). That way, when you (jason) can take sections of the data and
put it through the (converting machine) so then it gets labled right so then
the OSM renderer would accept it. ... but it would still stay in that before
rendering state (opentopomap) until those roads get manually tagged.  ..

I believe that IS possable for every road and WILL get visited eventually,
and only both ends of the roads that need to visited... travel along the
entire distance of the road isnt necessary when you take 3 left turns and
end up further down the same road.  .. so instead of manually acquiring all
the zig zags that the road might take, we would already have the road shown
exctly as it should be.  we then simply select it can tag it more details.

And in summery, for . "Canadian Geopolitical Boundaries" if not already
posted.. could also exist in that state too, but like in other countries OSM
should accept it as the only way to accuratly tell is from signs... However,
geobase is more accurate (as everyone else uses the same data)

and for "Canadian Geographical Names"
Keeping it in that middle state would be fine.

and for the water ways... "National Hydro Network", also in that middle

So for headach relief. .. when adding this data, it would only be when the
user views 'show gpx tracks' that the GeoBase data (convered to gpx would
get shown)... ... and .. using OpenTopoMap... this is where all the GeoBase
Data can be stored.. the road names would be available on that map.. and
visualy you can see what type of road it is. ... before it gets sent to
OpenTopoMap.. the information could get changed.

Does that make sence?

On Thu, Jul 24, 2008 at 11:30 AM, Jason Reid <osm at bowvalleytechnologies.com>

> I'd be against loading all of it, for the simple fact that your suggestion
> would cause far more headaches then its worth IMO. Take for instance
> Calgary. Most of the streets are there (and a significant number from GPS
> traces), if we imported even just the Geobase road data in to the main
> database, you're talking literally tens of thousands of ways that need to be
> gone over, many of which will be pretty much spot on to the existing data,
> and thats only for one city, and as a result most will either be left there
> (taking up enormous amounts of space on the server) or deleted. It also
> doesn't get us away from one of the main reasons we want the Geobase data,
> that theres no way that we'd ever map it all (beyond the populated areas of
> the country) if we only rendered stuff that we've verified exists in person.
> Not to mention that in order to not cause mass chaos we'd need to change
> all the tools (JOSM, Potlatch, Mapnik, Osmarender, possibly the API) to
> handle this special case of data, which is an unfair burden on the
> developers.
> The import script that I've been working on for the most part matches up
> the data to what the Canadian tagging schemes currently look like, the NRN
> data has a fairly similar set of levels of classification that for the most
> part that map over. The difference is mostly that each province has some
> different take on what level of highway is what (for instance between
> Alberta and Saskatchewan theres a number of highways that are primary in
> one, but considered secondary in the other as soon as it crosses the border,
> but the physical conditions don't change at all)
> I'm going to be taking a look at how the newest NRN dataset is structured,
> and from what I saw in the past it should be possible to split the data into
> either municipalities or worst case into some predefined blocks of a certain
> dimension for when we do the import. Worst case scenario for areas that
> there is already existing data for that we don't import we could setup an
> overlay so we can compare (Potlatch already has something for this, so for
> sure in it it should be doable) and just recreate the few missing areas that
> may be in the geobase data we don't have.
> -Jason Reid
> Sam Vekemans wrote:
>> A thought... because each road/line we draw on OSM has its own attributes.
>> ,,, and all the roads IF imported from GeoBase also has automatically a
>> tag
>> idendifier... just as our own user ID.. or the User ID of the last person
>> to
>> play with that road is marked.
>> . So it would be very easy to identify which road have been imported.. and
>> which roads have been created from 'scratch'.
>> .. Sure ALL the elements could be loaded to OSM.. but simply not rentered.
>> .. until someone comes along and puts theie human 'stamp of aproval'.
>> So then both, the OSM iser ID.. and the GeoBase reference id ar attached
>> to
>> the lines on the drawing.
>> the tagging would mean, selecting that toberendered item, and making sure
>> that it aligns with the OSM international tagging standard.
>>  .. ie. .. the user actually saw the river segment and and varify that it
>> exists. . .. the roads/river show up in the JOSM import (like when i do a
>> road and its in that state of waiting to be rendered) the roads still show
>> up. ...
>> So its like visually seeing tonnes of info already there, but is shown in
>> back and white.. the OSM users would select the info that they want to
>> share  and convert it into colour.
>> This way... it avoids any duplicate rendering.
>> There is always something more to add to the map that what GeoBase has to
>> offer. .. remembering that GeoBase does have TONNES of info. ... but it
>> doesnt list where the bicycle parking is.  ... so maybe in the data import
>> it shows already the school boundry... but then you see that it was labled
>> wrong... (or the coloquial name isnt listed) The OSM user can fix that and
>> tag everything that is known to be true... so then this stuff gets sent to
>> the renderer.
>> So in short.  I request that All GeoBase DOES get freely imported onto
>> OSM...  But only exists in that (between, tobe rendered state, and stays
>> there). .. .. so its only when you go and edit it that this information is
>> visable. ..
>> This way, we can continiously import new and future GeoBase data... as
>> well
>> as refine the rendered map.
>> This way, all OSM data is still created by OSM users putting there hands
>> on
>> the final product. .. as we know there is no final product. ... OSM is
>> Living Earth.
>> The other thing that GeoBase offers is that is shows Land Usage..
>> something
>> of importance to anyone. ... I think its fine if the stuff doesnt get
>> rendered until someone can physically see it.
>> ... ie. .. Im on a road and look out to the openpit mine. and because
>> GeoBase gives away all that data for free i can tag as much of the details
>> given by GeoBase.... at the same time as tagging a cycling route.
>> This solution would make OSM people happy, and the list of what has been
>> imported (in that tobe rendered state) .. the datasets could be listed on
>> the OSM wiki page and the status of it.
>> Thoughts?
>> Sam
>> On Thu, Jul 24, 2008 at 7:12 AM, Dale Atkin <datkin at ibycus.com> wrote:
>>  ------------------------------------------------------------------------
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca at openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-ca

Sam Vekemans' Facebook profile
(message me spam free and it's quickest this way)

Sam Vekemans
706 Yates Street
P.O. Box 8247
Victoria, BC
V8W 3R9

Direct: 250 588 9041
+001 250 588 9041
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20080724/8a147a9c/attachment.html>

More information about the Talk-ca mailing list