[Talk-ca] PEI NRN import 21I16 - and questions about ways

[Sam Vekemans]

Cool,
I was right :) (from the IRC)

route=road
type=route
ref=17
name=Highway 17

http://www.openstreetmap.org/browse/relation/417826

It Makes the magic happen with rendering.
http://www.openstreetmap.org/?lat=48.4746&lon=-123.3819&zoom=14&layers=B000FTF
you see the 17 3x
http://www.openstreetmap.org/?lat=48.4926&lon=-123.3693&zoom=12&layers=B000FTFrendered
2 times
http://www.openstreetmap.org/?lat=48.531&lon=-123.415&zoom=10&layers=B000FTFrendered
the HWY 17 once

And for each segment
http://www.openstreetmap.org/browse/way/25340664
We can keep them as separate pieces of road, and it's fine.

The UUID is useless and not needed... and 'cause where making an OSM map,
and CanVec will provide updates of the latest data as it becomes available
:-)

On Wed, May 12, 2010 at 5:57 AM, Richard Weait <richard at weait.com> wrote:

> On Wed, May 12, 2010 at 6:46 AM, Robert Shand <bob at shand.org.uk> wrote:
> > Hello Everyone,
> >
> > I've completed the initial steps of the NRN import for part of NW PEI.
>
> Hi Bob,
>
> Yay!
>
> [ ... ]
>
> > Take a look
> > at
> http://www.openstreetmap.org/?lat=46.8381&lon=-64.1547&zoom=13&layers=B000FTF
> >
> > Here we see the renderer has places lots of the markers for the road
> > number/name.
>
> No need to worry.  The frequent tertiary ref shields is a mapnik
> rendering setting in the shield symbolizer.  If you pop over to the
> osmarender layer you'll see that tertiary refs appear as numbers (not
> shields), that they appear less frequently, and that they don't appear
> until z14.
>
> [mapnik geeky aside]
>
> The rule for those shields is approximately this:
>
> ShieldSymbolizer name="ref" fontset_name="bold-fonts" size="10"
> fill="#fff" placement="line" file="&symbols;/ter_shield3.png"
> type="png" width="31" height="17" min_distance="40" spacing="750"
>
>
Cool (i think can make a custom OSM POI KML Google Earth file using the
highway shields)  Nifty


> So the shields will appear on ways as short as 40 pixels and repeat
> every 750 pixels on long ways.  Merging ways will reduce the number of
> shields you see when the uncombined ways are < 750 pixels long.
>
> [end mapnik geeky aside]
>
> > Taking a look at the data in JOSM we can see that the road 151 (like many
> of
> > the others) is comprised of many ways
> > http://www.shand.org.uk/osm/NRNImport/talk-ca/way1.png
> >
> > http://www.shand.org.uk/osm/NRNImport/talk-ca/way2.png
> >
> > However if I try to combine the ways I'm getting a conflict on the
> > geobase::uuid
> > http://www.shand.org.uk/osm/NRNImport/talk-ca/conflict.png
> >
> >
> > So my question boils down to how do we want to handle this.
> >
> > We shouldn't be mapping for the renderer, but the numerous markers on the
> > map do look odd.  In my mind the numerous ways should be combined into
> one
> > way, however if I do that I naturally have to lose some of the geobase
> data
> > like the uuid.  If we get newer higher quality geobase data matching up
> the
> > roads might more painful without the correct uuid.
> >
> > What are peoples thoughts?
>
> I'm not certain of The One Truth regarding this.  But here are some
> related thoughts.  Perhaps others will join the discussion as well.
>
> - combining the ways is not inherently bad.
> -- non-import ways tend to be longer.
> - combining the ways is more labour for you.
> - combining the ways only to fix the shield issue in mapnik _is_
> tagging for the renderer.
> -- we could submit a ticket to increase min_distance
> --- the current min_distance setting might work really well in denser
> road networks than the one we see in this example.
> -- we could render in a Canadian style and "fix" min_distance for
> ourselves.
> --- rendering in a Canadian Style requires a server, bandwidth and hosting.
> - combined ways should drop the uuids, rather than merge them (?)
>
-- the combined uuids will not correlate to a single uuid in any other
> system.
>


> -- the combined uuids may hint at what happened to the original uuids,
> but not at where the uuids were split.
> -- to recreate the original uuids, one would have to dive in to the OSM
> history
> --- if you have to dive into the history to find where the uuids were
> split, why not rediscover the uuids at the same time?
>


Just so to the source directly and find out.  (that's why we have
Attribution & source tags)  and look at the original SHP/OSM file to
cross-reference the validity of the data.

Cheers,
Sam

- combined ways may later need re-dividing if relations, bridges or
> other features are added.
>
> What do others think?
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20100512/a4ef43a7/attachment.html>