[Talk-ca] cleaning up after the GeoBase import

[Michael Barabanov]

Let me be a devil's advocate here for a while.  The 2 alternatives that make more sense are

- Delete the existing street data and start fresh with GeoBase, and always
   maintain the UUIDs properly. Given how many inconsistencies/topology
   errors there are in OSM data for Greater Vancouver, it may just be the right thing to do.
   Otherwise we'll be spending months joining exising OSM data to newly
   imported segments. Not a great way to spend resources.

- Don't pay attention to preserving UUIDs/segments, and re-run RoadMatcher when we need to import more data.

What we're doing right now is neither here nor there. No benefit of
GeoBase/UUIDs for existing OSM data and confused renderers for the imported GeoBase ones.

Michael.

On Fri, Jun 12, 2009 at 05:54:26PM -0600, James Ewen (ve6srv at gmail.com) wrote:
> On Fri, Jun 12, 2009 at 1:58 PM, William Lachance<wrlach at gmail.com> wrote:
> 
> > Right, you have to split up a way if the tags change as you describe.
> > However, there's also the (at the very least implied) convention that a
> > way should not be split if the tags don't change.
> 
> Yup, that's what I was doing when working by hand. Unless I had to
> split the way, it stayed as a single way, with multiple nodes
> necessary to define the path of the way.
> 
> > At best, the way we're
> > doing things will unneccessarily enlarge the OSM layer for Canada by
> > putting in redundant road tagging information into the database. At
> > worst, you cause problems with third party tools.
> 
> I agree with the bloat due to redundant tags. Each GeoBase way has an
> attribution, source, acquisition technique, and datasetname attribute,
> plus the UUID tag that would not be in the database without GeoBase
> data. The attribution is needed due to GeoBase requirements, and the
> UUID others are lobbying for. The source, acquisition technique, and
> dataset name don't seem to add much value to the database for me.
> 
> Still not sure where the third party tools you allude to come from
> though. I've never mentioned them, but you keep saying they will be
> required for special circumstances included in the GeoBase data.
> Please explain what would require third party tools.
> 
> > Look at this from another angle: Should we split up all the existing OSM
> > road data that people have put in to add in GeoBase UUID information?
> 
> I've asked the same thing... If some of the data can remain without
> Geobase attribute compatibility, why not the rest?
> 
> > Maybe I'm missing something, but I frankly just don't see the purpose in
> > tagging our data differently from the rest of the world, when we can
> > achieve the desired end (comparing OSM data to geobase) in an analytical
> > way simply by comparing the geometry and histories of both data sets
> > using tools like RoadMatcher. Perhaps this is a question we should put
> > to the larger openstreetmap community? I will fully admit I've only been
> > using and contributing to this project only sporadically for about a
> > year.
> 
> Same here... hopefully others can explain the other side of the debate
> for keeping a whack of extra Geobase information in the database. I
> can perch nicely on the fence here, and debate either side, as I'm not
> entrenched on either side. The only thing that I'm attached to, is
> making it easier to manipulate the data, either by merging adjoining
> ways, or changing the editing tools to be smarter.
> 
> James
> VE6SRV
> 
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca