[Talk-ca] Talk-ca Digest, Vol 10, Issue 1

[Richard Degelder]

On Tue, 2008-12-02 at 22:20 +0000, talk-ca-request at openstreetmap.org
wrote

> From: Richard Weait <richard at weait.com>
> 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 <matt.wilkie at gov.yk.ca>
> 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" <acrosscanadatrails at gmail.com>
> Subject: Re: [Talk-ca] importing GeoBase Data (learning from TIGER)
> To: "Steve Singer" <ssinger_pg at sympatico.ca>
> Cc: talk-ca at openstreetmap.org
> 
> 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" <acrosscanadatrails at gmail.com>
> 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" <acrosscanadatrails at gmail.com>
> 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" <acrosscanadatrails at gmail.com>
> 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