[Talk-ca] canvec2osm sample area tofino BC _with roads

Richard Weait richard at weait.com
Thu Apr 2 06:11:33 BST 2009


On Wed, 2009-04-01 at 21:06 -0700, Sam Vekemans wrote:

>         re:- a junction and a dead end?
>         On the dead_end layer is a node at the same point.  That
>         surprises me.
>         How can this be a junction and a dead end?  The "dead end
>         nodes" appear
>         at most road junctions.
> 
> 
> On the street i live on, right at the end before it gets to the main
> road.. it's actually blocked off to traffic.  so there is a little gap
> along the way.

What you describe above appears to be shown correctly in Pincher Creek
by barriers at the end of a very few ways.  

I see "dead end" nodes, co-incident with "many" junctions.  If they are
in fact barriers then large sections of Pincher Creek are not accessible
by car.  I accept that this is possible but think it unlikely.  Better
in that case to change the roads to footway or cycleway.  

> Along the some farm roads, the road does not connect to the main
> road... it did at one time, but now is only used for the farmers..  I
> have seen that when cycling along the crowsnest highway. ... where the
> highway paved though, but didnt want to connect to those side roads,
> due to the not wanted traffic.  In some cases it's a ditch with a
> barbed wire fence.

In this case it should be shown as a way not intersecting with the other
way.  I would be surprised if what you describe is what is on the ground
in Pincher Creek.  

> However, i could just list them (dead-ends) all as a 'turning circle'
> would that be better?

I doubt it.  I think it would be better to leave dead ends out unless we
can find out what they are supposed to represent.  What I expect them to
mean and what you describe, do not seem to be in line with where they
are located.  

> re:
>         - road names are broken.
>         Both roads (all four segments) have defined values for
>         canvec:L_STNAME,
>         canvec:R_STNAME but name="-"  We'll get more from the import
>         if we
>         populate name.  Ideally we can populate name when L_STNAME =
>         R_STNAME,
>         and use the two names when they differ.
>    
> That would be called 'SmartMatching" something that the OpenJUMP
> software could 'probably' do.  
> running an IF / THEN script would handle it.
> This is something that can be done after the import happens, as a
> 'bot' (fortunately it would be user "geobase:Acrosscanadatrails" and
> not my regular user name for when that would happen)

> I'll have to ponder that one for a bit :)

Without an if/then solution, making name = R_STNAME is a better default
than leaving it blank.  

> re:
>         - "-" for null
>         Several properties are set to "-" when they should be unset /
>         null / not
>         used.
> 
> 
> "-" is actually the numerical value that is showing in the database
> file, but i'll have to ponder that one too :)

No need to ponder it.  Just don't add a tag "-".  "-" is wrong.

> re:
>         - contours are broken and not in OSM
>         The contour_imperial layer is 7MB and the largest layer in the
>         Pincher
>         Creek data.  You should get broad support for importing this
>         data from
>         talk before you consider including contours in the import.
>          Even if you
>         find that support, this contour layer is of very little use.
>          There is
>         no elevation data in the contour vectors.
> 
> 
> I dealt with that one already, but will further explain it on the
> wiki :)
> In short, i have it included in the script, and in the 'extra' folder,
> as they will be helpful for creating custom Garmin Maps.

Cool.  As long as they aren't uploaded without community support.  

On topo / contours.  I know that they are important to your commercial
interest in OSM.  As implemented they appear to just be squiggly lines.
Are they still useful to you without a value for the elevation?  This
just seems so wrong, when compared to the DEM used by OpenCycleMap and
others.  

>         - duplicate data in islands and water bodies
>         Waterbody layer includes internal and external boundaries.
>          Island layer
>         duplicates those internal boundaries.

> Having these duplicates should be fine.  It clearly indicates what is
> land and what is water.

Relations for water with inner / outer boundaries clearly show what is
land and what is water.  Perhaps the island outlines can be dropped
entirely.  They duplicate inner boundaries in Pincher Creek.  

> Omiting the 'inner' part of the waterbody would not be showing the
> data acuratly.  

Which is why I suggest keeping it.  
> 
>         - named features missing name:en
>         Scotts Coulee, for example, has name and name:fr set, but not
>         name:en
>         They should probably all be the same unless language specific
>         names are
>         provided.
> 
> 
> I dont want to have the label shown twice as it would be a duplicate
> node and hard to read.  

Why do you think this would cause duplicate labels?  My understanding of
the renderers is that name is renderered by default.  Settings can be
changed to use name:other or something else.  

> (As a reminder) the canvec2osm 'train' runs much much slower than
> geobase2osm, it stops and is manually looked at all the way
> along.  ... about the pace of a bicycle :)

I'm getting lost in your 'train; and 'q-tip' references.  Perhaps you
can put these comments in context in future.  





More information about the Talk-ca mailing list