Re: [Talk-ca] Vancouver campus data

[Gregory]

I finally got some contact details from my geography teacher that seem like
they might be the place to go. At some point I'll be documenting stuff in
the wiki, so I started now:
http://wiki.openstreetmap.org/wiki/Canada:British_Columbia:Vancouver/UBC

That
includes a pdf sample of the data. Note it has every single bollard and
cycle rack even if they are bunched up next to each other. However cycle
racks don't have capacity like OSM does, so 4 cycle racks might only take 4
bikes each, or they might take 40 bikes each.

Please comment (on the wiki talk/discussion page?) on my list of what is
good for OSM, soon I will probably be telling them what I'll import.

Greg.

On 29 March 2010 23:41, Adam Dunn  wrote:

> Many bike racks are also under cover (Buchanan and Dempster come to mind),
> so good luck spotting them on Yahoo. I can also attest to the fact that
> Yahoo is not very well orthorectified for UBC, especially in the theology
> department and Gage towers. I think Fairview was okay though...
>
> I don't see how using PlantOps maps to plan a day's outing could be
> considered derivative work though. If Gregory goes to the location on foot
> and marks a gps point for the bollards on Main Mall near Forestry, then it's
> his own work. Looking at PlantOps maps to see that there is something
> interesting in the area shouldn't really count as an original source.
>
> Adam
>
> P.S. Sorry about the duplicate email Russell.
>
>
> On Mon, Mar 29, 2010 at 7:32 PM, Russell  wrote:
>
>> Unfortunately the yahoo imagery in Vancouver isn't good enough to see
>> bike racks anyways :(
>> The yahoo imagery at UBC is distorted also (wavy) on part of the campus.
>>
>> Regardless, if we want to make a demo area at UBC with very high
>> detail mapping, then I would like to help as I am a student out there
>> as well.
>>
>> The orienteering club has done a great job of mapping the campus over
>> the last few years (this is the map from a while ago, now the entire
>> campus is mapped:
>> http://www.orienteeringbc.ca/gvoc/maps/files/UBC.gif)
>> Unfortunately they do trace imagery so it isn't suitable for importing I
>> think.
>>
>> Russell
>>
>> On Mon, Mar 29, 2010 at 7:08 PM, Corey Burger 
>> wrote:
>> > On Mon, Mar 29, 2010 at 7:00 PM, James Ewen  wrote:
>> >> On Mon, Mar 29, 2010 at 11:37 AM, Corey Burger 
>> wrote:
>> >>
>> >>> Bicycle racks would certainly be a welcome addition. I look at the
>> >>> number around UVic and shudder.
>> >>>
>> >>> However, who holds copyright on the data? They need to sign off on
>> >>> importing it into OSM if it isn't licensed under fairly liberal terms.
>> >>> If you don't know then it is likely all rights reserved. Plant Ops may
>> >>> not have the ability to do this. Likely you are going to need to clear
>> >>> it through Legal, which can add time and headaches.
>> >>
>> >> So this brings up a question for me...
>> >>
>> >> If Gregory were to wander around the campus, and mark the bike racks
>> >> on his GPS, and upload that to OSM, it would be completely kosher.
>> >>
>> >> What if Gregory were to plan his outing to collect information by
>> >> referencing the copyright information in the campus map. Would that
>> >> make his information a derivative work? I would think not.
>> >
>> > If you are using the map to navigate, I think there is a pretty strong
>> > argument for deriviativeness. Better to simply wander around and find
>> > them in a very systematic way.
>> >
>> >>
>> >> What if Gregory were to reference the location of the bike racks on
>> >> the campus map, and then use the Yahoo Map images to locate the bike
>> >> racks, and mark them on OSM. Would that now be a derivative work? This
>> >> I don't know...
>> >
>> > Yes, this definitely would be, because there would be no actual ground
>> truthing.
>> >
>> > Corey
>> >
>> > ___
>> > Talk-ca mailing list
>> > Talk-ca@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-ca
>> >
>>
>>
>>
>> --
>> Russell
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
>


-- 
Gregory
o...@livingwithdragons.com
http://www.livingwithdragons.com
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Editing intersections on dual carriage-ways

[Richard Weait]

On Wed, Apr 7, 2010 at 12:37 PM, Marc Provencher
 wrote:
> I searched, but could find no tutorial on an agreed way of properly mapping
> an intersection of two dual-carriage ways, ie an intersection of two
> residential roads where the ways are divided by a center boulevard, along
> with mini right turn ramps on all four corners (see picture link below).
>
> http://provencher.smugmug.com/Other/Misc/Intersection/830343527_po6Yx-X3.jpg
>
> In this picture, I think junction nodes B and G are not needed. Technically,
> if your vehicle is at B, you are not even legally allowed to turn right
> anyways. Same for G.

HI Marc,

You raise interesting points.  I've seen different ways of modeling
this type of intersection.  I've used your example often and I place
connecting nodes at B and G as well.  I do this because they are
essentially the same carriageway, at the same level.  While a turn is
not normally permitted, it is certainly possible, say, if the flare is
blocked by a collision.

If you were to leave the two crossing roads with no node, that would
raise an error in a number of OSM error detection tools, like
keepright[1] because the ways cross but are not connected.  This is
acceptable when the ways are on different layers, as with a bridge.
This suggests to me that OSM has decided it is customary to place
joining nodes at B and G.

I have seen models where each junction is pinched to a single
carriageway, sort of like this:

===--o--===

where the "=" are dual carriageway "-" single carriageway and "o" is
the junction node with the cross street.  This simplifies each
junction to a single node, but at the expense of taking more time to
map.

> Another question that arises, and for which I haven't seen a definite
> answer, is what to do about the "middle" segments in the intersection. In
> the picture above, if Road1 and Road2 have the same name, then they could be
> drawn as a contiguous road segment, going through A-B-C-D.

I do that when the road name does not change.

> But what if Road1 ends at this intersection, and Road2 begins there as
> well?  Do you draw Road1 all the way thru junctions A-B-C, and then draw
> Road2 thru junctions B-C-D? After all, if I'm heading southbound and want to
> turn left onto Road2, I would want my routing directions to say "turn left
> on Road2", not "turn left on Road1", which it might say if the segment
> between B and C only belongs to Road1.

I think I have been lazy in this regard.  I'm not sure I use a
consistent rule when I build these intersections.

B and G seem like good places to change the name of road 1 and 2.
That leaves a weird, mid-junction area where on side is road 1 and the
other is road 2.  Given this, from the north your nav-program would
advise "turn left on Road 2" or exit right to Road 1 if you were going
the other way. From the south, the nav-program instructions are okay
as well.  From the East and West, this seems to work as well,
"continue straight to Road 2"

I think this model still works if there are no flares on the
intersection as well.

> I have seem much more complex intersections as well, with separate left turn
> lanes. I somewhat fail to see the point in modeling the intersections so
> accurately, if it doesn't really add anything to a routing GPS?

I agree.  A routing GPS for cars should be the only application we
consider when we map.  But we shouldn't go out of our way to make
things difficult for a common use.

Others find mapping individual lanes irresistible, but I believe this
is a very small proportion of OSM contributors.  I'll map a left run
lane if I would map it as a flare; if the flare is just dome paint and
no hard curb, I'm unlikely to map it.

Every mapping project faces these issues.  "Where is the line between
worth-mapping and not-worth-mapping".  We won't all agree.

There is an area with detailed micro-mapping of sidewalks, grassy
medians, parking and driving lanes, and building lots.  It hasn't
expanded since it was added.  It may be that the micro-mapper just
found it too much work.  It's also a horrible example of mapping for
one specific renderer.  It looks bad in any other renderer, and it
even looks bad in the intended renderer, if you change zoom levels
from the one used when the data was drawn.


[1] http://keepright.ipax.at/

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Editing intersections on dual carriage-ways

[Marc Provencher]

I searched, but could find no tutorial on an agreed way of properly mapping
an intersection of two dual-carriage ways, ie an intersection of two
residential roads where the ways are divided by a center boulevard, along
with mini right turn ramps on all four corners (see picture link below).

http://provencher.smugmug.com/Other/Misc/Intersection/830343527_po6Yx-X3.jpg

In this picture, I think junction nodes B and G are not needed. Technically,
if your vehicle is at B, you are not even legally allowed to turn right
anyways. Same for G.

Another question that arises, and for which I haven't seen a definite
answer, is what to do about the "middle" segments in the intersection. In
the picture above, if Road1 and Road2 have the same name, then they could be
drawn as a contiguous road segment, going through A-B-C-D.

But what if Road1 ends at this intersection, and Road2 begins there as
well?  Do you draw Road1 all the way thru junctions A-B-C, and then draw
Road2 thru junctions B-C-D? After all, if I'm heading southbound and want to
turn left onto Road2, I would want my routing directions to say "turn left
on Road2", not "turn left on Road1", which it might say if the segment
between B and C only belongs to Road1.

I have seem much more complex intersections as well, with separate left turn
lanes. I somewhat fail to see the point in modeling the intersections so
accurately, if it doesn't really add anything to a routing GPS?

Thanks for sharing your thoughts and guidance on this.

-- 
Marc Provencher
m...@marcprovencher.com
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Atlas of Canada WMS layer for more parks

[Sam Vekemans]

Hi all,
As an addition to the NRCan Natural protected areas .osm file i
announced the other day, we now have access to those other parks that
are not listed in the 7 .osm zip file set.
These are at a scale of 1:1 million, but better than not having the
data. (so 1/2 as good, but in some cases you cant tell the difference)

Adam Dunn put together a link for both the park names & the polygons.
Just add/remove features as you like.

http://atlas.gc.ca/cgi-bin/atlaswms_en?VERSION=1.1.1&request=GetMap&SRS=EPSG:4326&LAYERS=can_1m_protect,can_1m_protect_nam,int_bounds,na_road,na_rail,na_coast&STYLES=&FORMAT=image/png&;

(it's also handy to have as a backdrop for when your looking at the
Natural Protected Area's file.
http://wiki.openstreetmap.org/wiki/Geobase/NRCan_Protected_Areas

I made a wiki page for it, listing the scale and what tags are most recommended.
The license looks to be super.
http://wiki.openstreetmap.org/wiki/Atlas_of_Canada#Available_Data

Whats nifty is that there is a National Marine protected area way out
in the pacific, but still in Canada waters.
http://www.openstreetmap.org/browse/way/54601371

You can see on the 'int_bounds' layer that Canada extends out that far.
http://atlas.gc.ca/cgi-bin/atlaswms_en?VERSION=1.1.1&request=GetMap&SRS=EPSG:4326&LAYERS=int_bounds,na_coast&STYLES=&FORMAT=image/png&;

 ... i didn't adjust the geobase boundary as i want to make sure that
others agree on it 1st.  Perhaps this could be drawn as the 'Canadian
International waters boundary' or something?

Cheers,
Sam

-- 
Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
OpenStreetMap IRC: http://irc.openstreetmap.org
@Acrosscanadatrails

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca