[Talk-ca] [talk-au] New CC-BY datasets due Monday 28 September on Government 2.0 Taskforce website

[Sam Vekemans]

On Sun, Oct 4, 2009 at 6:14 PM, John Smith <deltafoxtrot256 at gmail.com>wrote:

> 2009/10/5 Sam Vekemans <acrosscanadatrails at gmail.com>:
> > Just one comment.  If it was me working on it, i would hesitate on adding
> in
> > roads where they are 'estimated' because it is not known as a fact.  Once
> > all the property boundaries are in there, i think that will cause a
> natural
> > 'growth' in OSM activity, and people would want to help out ... by going
> > along that way with a GPS, and getting some tracks.  so not even listing
> a
> > highway=road, might be the best way to go.  IMO
>
> Actually anyone that knows a road exists but hasn't had a chance to
> map it by other means could use the property boundaries to do so, no
> GPS needed etc.
>
> That's true. .. so someone who's kind-of familiar with the area (been down
the road at least once in their life?


> Also Qld alone makes up 1/4 of the area of Australia, but has
> relatively few people (4.2 mill according to wikipedia), most live in
> the very south east of the state around Brisbane.
>
> My point is, the majority of back roads, and even streets in tiny
> little out back towns aren't going to be mapped by GPS, at least not
> for a decade maybe more.
>
>
Perhaps maybe the suggestion is to hold off on that planning aspect, or
rather,not concentrate efforts on it, as the data may become available
later?

I saw the link of 'streams' pop up, perhaps when all data that is available
is imported, then deal with what isn't available :)


> > Once a few tracks (even 1 will do) whoever is tracing there own tracks
> will
> > have a 'guide' to work with already.   This way, we will know for sure
> that
> > roads exist where they do in real-life.
>
> Those traces just don't exist and most likely won't exist.
>
> True :)


> > It will also give an opportunity for that local area mapper to add in
> other
> > POI along the way. :-)
>
> Yes, there is no street names or POIs on property boundary data :)
>

So a lesson from Alberta is that there have been a few people who spent lots
of time traveling the back-roads, collecting road names. or lots of tracing
(before data became available)

So the only thing that i can recommend is to 'not actively encourage'.
.... but then, how can you not actively encourage mapping? (rhetorical)

So thats where we needed to draw the line.  The method of 'making data
available, so people can copy what they like, is probably better than 1
person importing it all at once.   Purpose being to get it done FAST, rather
than the passive approach of 'top quality'.

Considering that im in Victoria, BC and converting the data. And others who
live in or areas would know what data is more accurate that i would.

Example Calgary, Alberta

So by me making the data available (all the railways/buildings... all canvec
data) and all the river data simply 'available'.  Then we can have local
people volunteering to copy-in the data n that they know is more accurate.
Also, they already know what rivers they traced, and (if it was roads) would
already know what roads they drew in.

So by making it available (rather than even using AutoMatch), the local area
mapper who spent the last 2 years tracing and drawing in their roads, will
probably be a bit happier with copying in features... rather than someone in
Victoria (1/2 a country away) dropping data in, all around them.

What i have been doing, is contacting the local area mappers (for the 092,
Vancouver island area) and using that as a test-area)  Because i am familiar
with most of it now.   And i found that the local area mappers are focused
on the local area :)  and that as soon as i started to drop-in data for
their area... that spurred more mapping (even them adding in stuff that i
was just about to have added in).

So (instead) by making ALL the data converted. ... local people can copy in
what they like.   It (probably) will still be only a few of us who end up
copying in the majority,  but at least it will be more local people.

Then, as new data is available, the data conversion part is done separately,
and the data is simply made available for people to copy at their leisure.

The method of using 'AutoMatch' is the same, accept instead of comparing the
SHP files, we are comparing the new .osm files with the current .osm area,
and creating a DIFF file and looking at the matches that it found.

It's just making the import as a 3 separate step process rather than trying
todo it all at once.
1 - Data conversion
2 - Data sharing
3 - Data importing

So when updates are available, it is just converting it to .osm format so
then after step 3, we have
4 - Data AutoMatch (merging 'missing' map features)  (with OpenJUMP in a
PostGIS database)

Then stuff like fixing the 'source' tag can all be done after the fact. with
step 5.

5 - update source tags
As that process can be done with a program (bulk_update.pl) that grabs the
.osm area, attaches on and changes tags, then imports back the changes.
And in a small scale JOSM can do that too.

BTW, even though a dataset like the property boundary wont interfere with
existing OSM data, this method can still be used.  It just can go alot
faster.   ... IMO, it needs to happen, as thats the best way to deal with
updates.  (you can compare the currently available .osm files to the newly
available .osm files)  as well as compare the local OSM area .osm files.
And without having this source data available, it makes it alot harder.

And one last point, (as i rattle on) so for the areas that have been mapped,
having someone more local copy in the data themselves, then it would
'empower' them to be able to move their own roads that they already mapped
into a more correct location. (rather than someone from another town)


> > Another note, is bigtincan hosting a planet-dump and diff/load for your
> > slippy map?
>
> Only of south eastern Asia and the south western Pacific, the server
> would be capable of more, but lacks hdd space.
>
> > ... and what do you think of my way of conducting the import (just making
> > the .osm files available (hosting them on mediafire.com), and letting
> local
> > are mappers drop-in the data at their leisure? and organizing it all with
> a
> > Googledocs chart?   (itching for feedback here)
>
> You do know there is 2.1million property boundaries right?
>
It's the 'method' the actual import can be automated, i got oodles of rivers
in Canada too :-)  ... just like the method of actual data conversion is
(now) automated. :-)


>
> > Is BTC mapper going to add Garmin Maps to that list?
>
> Several people already do Garmin maps, I didn't see much point to it.
> The major reason for getting a tile server up and running was highway
> shields...
>
> > P.S.  Yup, i knew that the government would open up, it was just a matter
> of
> > time.  :-)  ... i guess the rest of the common wealth countries might be
> > next.   Only, if the Queen says so. ;)
>
> I think part of the reason the data was released is due to a change of
> federal government, who do some truly good things and then turn round
> and screw it all up with bone head ideas like filtering people at the
> ISP level.
>

Ya, so the though that 'the source data files' aren't going anywhere, is not
exactly true.  Any new government can go in there and scrap or improve on
whatever departments they want. ... i think usually it would be either
improve... or delay improvements :)

....  which is another reason why im making a backup copy of the source shp
files as im going along. :-)

Hope that helps,
..... Over the next couple months i will be working on the wiki explaining
the process and method MUCH more clearer than it currently does. (since now
there is proven method to the madness)

Cheers,
Sam Vekemans
Across Canada Trails
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20091005/48ee3f1b/attachment.html>