[Talk-ca] Tagging of roads in Vancouver

[Paul Norman]

I've been looking at the tagging practices in the lower mainland and the
documentation on the wiki. I'm having trouble finding a consistent practice,
particularly around residential collectors.

 

Is there a consistent practice?

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

Re: [Talk-ca] Tagging of roads in Vancouver

[Paul Norman]

The big issue I'm having around New Westminster is that everything is tagged
residential, with the few streets that are tagged all being tagged as
secondary I've tagged some of the major residential collectors. 
Some examples.

10th Ave (99A/1A) is tagged as secondary, the same as 10th Ave East, which
isn't part of the 99A/1A, and has two lanes and is of a quite different
character. These are both tagged the same as the Lougheed Highway in the
Burnaby/Coquitlam region, which is a 4-6 divided highway.

It seems like the only tanks in use are essentially secondary, motorway, and
residential.

To me it would make more sense if the major routes such as Lougheed,
Kingsway, 99A/1A, Granville, Oak, etc were primary, with routes like the
Lougheed where it is divided and the Mary Hill being tagged as Trunk or
Motorway since they are divided highways with very few intersections.

-Original Message-
From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Richard Weait
Sent: Thursday, October 07, 2010 5:46 AM
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Tagging of roads in Vancouver

On Thu, Oct 7, 2010 at 8:24 AM, Paul Norman  wrote:
> I've been looking at the tagging practices in the lower mainland and 
> the documentation on the wiki. I'm having trouble finding a consistent 
> practice, particularly around residential collectors.
>
> Is there a consistent practice?

Well there should be some consistency.  Can you link to areas that concern
you?  Let's have a look.

___
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

[Talk-ca] UBC, Vancouver orthography, and street alignment

[Paul Norman]

UBC in Vancouver has been suffering from issues of building misalignment
because the Yahoo orthography is misaligned with the ground and suffers from
distortion[1]. The City of Vancouver offers some mapping data [2] which can
be used with OSM. I've taken 16 tiles that cover most of UBC and corrected
most of the streets to these as these reflect the GPS traces, CanVec data,
and my knowledge from being a student. They are also high resolution, being
listed as 40cm, but I can easily make out smaller features. 

I've also done some micro-mapping around the SUB, Buchanan, the Chan Center
and Rose garden, and down by CEME.

As the process to convert the .ecw files is a long and computationally heavy
one if anyone wants the resulting slippymap which can be used with the JOSM
slippymap plugin and is regularly at UBC I could burn them onto a CD.

I also have all of Vancouver processing to make a slippymap, but it has only
been about 25 hours so it is not finished yet. If anyone wants that, it'll
take multiple DVDs. Of course, anyone could recreate it from the downloaded
files but anticipate gdal2tiles taking about 30-40 hours on a good computer.

If anyone notices misaligned streets at UBC and isn't able to get the
Vancouver orthography working I'd appreciate knowing and I can align them.

[1]

[2] 


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

Re: [Talk-ca] UBC, Vancouver orthography, and street alignment

[Paul Norman]

CanVec was what I aligned to. That and local knowledge - I know parts of UBC
extremely well, having been there for about 7-8 years. 

If the Vancouver license isn't compatible with OSM the wiki should be edited
- it says it's acceptable as is.

-Original Message-
From: samvekem...@gmail.com [mailto:samvekem...@gmail.com] On Behalf Of Sam
Vekemans
Sent: Sunday, October 31, 2010 6:25 AM
To: john whelan
Cc: Paul Norman; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] UBC, Vancouver orthography, and street alignment


were still waiting for OpenStreetMap to change it's licence :) lol...
but anyway, geocommons.com is a good temporary home for the p files :) and
having the data on standby just waiting to use used is helpfull.


cheers,
sam

On 10/31/10, john whelan  wrote:
> I was under the impression that the City of Vancouver "Open" data 
> along with Ottawa's and Calgary's wasn't quite open enough for OSM 
> use.  I assume you aligned with CANVEC data and merely visually 
> confirmed it against Vancouver's data?
>
> I understand they were looking at changing the license, if you have 
> any news on this I'd be grateful.
>
> Thanks John
>
> On 31 October 2010 00:18, Paul Norman  wrote:
>
>> UBC in Vancouver has been suffering from issues of building 
>> misalignment because the Yahoo orthography is misaligned with the 
>> ground and suffers from distortion[1]. The City of Vancouver offers 
>> some mapping data [2] which can be used with OSM. I've taken 16 tiles 
>> that cover most of UBC and corrected most of the streets to these as 
>> these reflect the GPS traces, CanVec data, and my knowledge from 
>> being a student. They are also high resolution, being listed as 40cm, 
>> but I can easily make out smaller features.
>>
>> I've also done some micro-mapping around the SUB, Buchanan, the Chan 
>> Center and Rose garden, and down by CEME.
>>
>> As the process to convert the .ecw files is a long and 
>> computationally heavy one if anyone wants the resulting slippymap 
>> which can be used with the JOSM slippymap plugin and is regularly at 
>> UBC I could burn them onto a CD.
>>
>> I also have all of Vancouver processing to make a slippymap, but it 
>> has only been about 25 hours so it is not finished yet. If anyone 
>> wants that, it'll take multiple DVDs. Of course, anyone could 
>> recreate it from the downloaded files but anticipate gdal2tiles 
>> taking about 30-40 hours on a good computer.
>>
>> If anyone notices misaligned streets at UBC and isn't able to get the 
>> Vancouver orthography working I'd appreciate knowing and I can align
them.
>>
>> [1]
>> <
>> http://wiki.openstreetmap.org/w/index.php?title=Canada:British_Columb
>> ia:Van 
>> couver&oldid=552230#University_of_British_Columbia<http://wiki.openst
>> reetmap.org/w/index.php?title=Canada:British_Columbia:Van%0Acouver&ol
>> did=552230#University_of_British_Columbia>
>> >
>> [2] <http://data.vancouver.ca/datacatalogue/>
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-ca
>>
>


--
Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room)
@Acrosscanadatrails


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

Re: [Talk-ca] UBC, Vancouver orthography, and street alignment

[Paul Norman]

Just for reference, the following URLs will work for "service URL" in JOSM

http://openmaps.gov.bc.ca/mapserver/base2?service=WMS&REQUEST=GetCapabilitie
s 

http://openmaps.gov.bc.ca/imagex/ecw_wms.dll?FORMAT=image/jpeg&VERSION=1.1.1
&SERVICE=WMS&REQUEST=GetCapabilities



> -Original Message-
> From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-
> boun...@openstreetmap.org] On Behalf Of Tonkin, Bruce ILMB:EX
> Sent: Monday, November 01, 2010 9:06 AM
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] UBC, Vancouver orthography, and street alignment
> 
> Paul,
> 
> To verify your data you could also use the Province of BC's WMS
> Services. Here are two that you may find useful for the UBC Area.
> 
> Road Network:
> http://openmaps.gov.bc.ca/mapserver/base2?service=WMS&REQUEST=GetMap&SER
> VICE=WMS&VERSION=1.1.1&LAYERS=DRA_DIGITAL_ROAD_ATLAS_LINE_SP&STYLES=&FOR
> MAT=image/png&BGCOLOR=0xFF&TRANSPARENT=TRUE&SRS=EPSG:4326&BBOX=-123.
> 265021881044,49.2499715666015,-123.232373077585,49.2776350737241&WIDTH=1
> 002&HEIGHT=849
> 
> 100mm Orthophoto:
> http://openmaps.gov.bc.ca/imagex/ecw_wms.dll?REQUEST=GetMap&SERVICE=WMS&;
> VERSION=1.1.1&LAYERS=REGIONAL_MOSAICS_BC_GVRD_WEST_XC100MM_UTM10_2009&ST
> YLES=&FORMAT=image/png&BGCOLOR=0xFF&TRANSPARENT=TRUE&SRS=EPSG:4326&B
> BOX=-123.27242922767,49.2358356991024,-123.218014555238,49.2819415443068
> &WIDTH=1002&HEIGHT=849
> 
> 
> Thanks,
> 
> Bruce Tonkin
> 
> -Original Message-
> From: talk-ca-boun...@openstreetmap.org
> [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of talk-ca-
> requ...@openstreetmap.org
> Sent: Sunday, October 31, 2010 5:00 AM
> To: talk-ca@openstreetmap.org
> Subject: Talk-ca Digest, Vol 32, Issue 16
> 
> Send Talk-ca mailing list submissions to
>   talk-ca@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.openstreetmap.org/listinfo/talk-ca
> or, via email, send a message with subject or body 'help' to
>   talk-ca-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   talk-ca-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Talk-ca digest..."
> 
> 
> Today's Topics:
> 
>1. UBC, Vancouver orthography, and street alignment (Paul Norman)
> 
> 
> --
> 
> Message: 1
> Date: Sat, 30 Oct 2010 21:18:03 -0700
> From: "Paul Norman" 
> To: 
> Subject: [Talk-ca] UBC, Vancouver orthography, and street alignment
> Message-ID: <000301cb78b2$9c973c60$d5c5b5...@mac.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> UBC in Vancouver has been suffering from issues of building misalignment
> because the Yahoo orthography is misaligned with the ground and suffers
> from distortion[1]. The City of Vancouver offers some mapping data [2]
> which can be used with OSM. I've taken 16 tiles that cover most of UBC
> and corrected most of the streets to these as these reflect the GPS
> traces, CanVec data, and my knowledge from being a student. They are
> also high resolution, being listed as 40cm, but I can easily make out
> smaller features.
> 
> I've also done some micro-mapping around the SUB, Buchanan, the Chan
> Center and Rose garden, and down by CEME.
> 
> As the process to convert the .ecw files is a long and computationally
> heavy one if anyone wants the resulting slippymap which can be used with
> the JOSM slippymap plugin and is regularly at UBC I could burn them onto
> a CD.
> 
> I also have all of Vancouver processing to make a slippymap, but it has
> only been about 25 hours so it is not finished yet. If anyone wants
> that, it'll take multiple DVDs. Of course, anyone could recreate it from
> the downloaded files but anticipate gdal2tiles taking about 30-40 hours
> on a good computer.
> 
> If anyone notices misaligned streets at UBC and isn't able to get the
> Vancouver orthography working I'd appreciate knowing and I can align
> them.
> 
> [1]
> <http://wiki.openstreetmap.org/w/index.php?title=Canada:British_Columbia
> :Van
> couver&oldid=552230#University_of_British_Columbia>
> [2] <http://data.vancouver.ca/datacatalogue/>
> 
> 
> 
> 
> --
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
> 
> 
> End of Talk-ca Digest, Vol 32, Issue 16
> ***
> 
> ___
> 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

[Talk-ca] Surrey Data

[Paul Norman]

The City of Surrey has released their GIS data under the PDDL at
http://www.surrey.ca/city-services/658.aspx

Included in this is addresses for the entire city, lamp posts, manholes.
I've glanced at some of the files in ArcGIS Explorer and the level of detail
in them is excessive if anything. That being said, I wonder if there's some
stuff worth importing.

What interested me is the orthography data, being PDDL. They have 2008 in
GeoTiffs at http://www.surrey.ca/city-services/4911.aspx and a 2010
slippymap at
http://cosmos.surrey.ca/ArcGIS/rest/services/ORTHO2010/MapServer

The 2008 are 40cm resolution color, and the 2010 are 10cm resolution color.


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

Re: [Talk-ca] Surrey Data

[Paul Norman]

I think the most useful is the orthophotos, followed by the address data,
followed by traffic signals. From what I've seen the alignment for roads in
surrey is pretty good already, although it might be worth converting those
so they can be used as a background like I do with CanVec.

 

For data like the light standards it would be cool if we could do lit= from
them, but importing the light nodes themselves might be an issue. Although
there is a tag for a node to mark it as a streetlight, keeping any nodes
added up to date with any changes would be hard. 

 

I definitely think that it's pretty cool that they've made available all
this detailed data and essentially left it to the users to decide what is
relevant. It may be that some of the data never gets used, on the other
hand, if I wanted to go and look at the efficiency of surrey street lights
by area based on lamp type, they've given out enough detail to do so.

 

From: Adam Dunn [mailto:dunna...@gmail.com] 
Sent: Tuesday, November 02, 2010 12:44 PM
To: Paul Norman
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Surrey Data

 

Asked on irc, and PDDL is okay to import, so we can do this one if we want.

Lots of great stuff in here. The transport file comes with 5 shapefiles:
traffic signals, sidewalks, road edges, road centrelines, and poles.

Traffic signals has traffic lights, pedestrian lights, beacons (which I
think are flashing red/yellow, will need a local to check some of this out),
and "fire" (probably stop lights in front of a fire department). Also
contains whether the lights are controllable, and who owns them (Surrey,
provincial, etc), among other info.

Sidewalks has outlines of sidewalks, some of them have material
(concrete/asphalt) and width, among other info.

Road Edges has the outline of roads (very high detail), along with all the
private driveways along the roads (driveways that are 1 or 2 car lengths
even!), but there's not much tag info of use here.

Road Centrelines has name, class (provincial highway, arterial, local),
surface type, maxspeed, route usage (dangerous goods, truck route), number
of lanes, address info (leftfrom, rightfrom, leftto, rightto) and owner,
among other info. The address info would be good to get, but it's tagged
onto the centreline itself, so one would have to generate separate ways for
the interpolation.

Poles has light poles, with the type (hydro pole with lights, street lights,
primary/secondary signal lights, private property lights), material
(concrete, wood, metal), colour (green, silver), height, lamp type (metal
halide, led, sodium), wattage, and particularly interesting in the comments
is the existence of a camera. This info could be good for filling in the
lit=yes value for various roads.

Adam

On Mon, Nov 1, 2010 at 3:20 PM, Paul Norman  wrote:

The City of Surrey has released their GIS data under the PDDL at
http://www.surrey.ca/city-services/658.aspx

Included in this is addresses for the entire city, lamp posts, manholes.
I've glanced at some of the files in ArcGIS Explorer and the level of detail
in them is excessive if anything. That being said, I wonder if there's some
stuff worth importing.

What interested me is the orthography data, being PDDL. They have 2008 in
GeoTiffs at http://www.surrey.ca/city-services/4911.aspx and a 2010
slippymap at
http://cosmos.surrey.ca/ArcGIS/rest/services/ORTHO2010/MapServer

The 2008 are 40cm resolution color, and the 2010 are 10cm resolution color.


___
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

Re: [Talk-ca] Surrey Data

[Paul Norman]

I talked to someone with their GIS department today and they plan on
releasing their 2010 orthographs in a few days. They also plan on
downsampling the data because each tile is ~1 GB, leading to a total size of
120 GB or so. I'm also talking with them about getting the data from the
edges which are outside their tile system but photographed.

> -Original Message-
> From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-
> boun...@openstreetmap.org] On Behalf Of Paul Norman
> Sent: Monday, November 01, 2010 3:21 PM
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] Surrey Data
> 
> The City of Surrey has released their GIS data under the PDDL at
> http://www.surrey.ca/city-services/658.aspx
> 
> Included in this is addresses for the entire city, lamp posts, manholes.
> I've glanced at some of the files in ArcGIS Explorer and the level of
> detail in them is excessive if anything. That being said, I wonder if
> there's some stuff worth importing.
> 
> What interested me is the orthography data, being PDDL. They have 2008
> in GeoTiffs at http://www.surrey.ca/city-services/4911.aspx and a 2010
> slippymap at
> http://cosmos.surrey.ca/ArcGIS/rest/services/ORTHO2010/MapServer
> 
> The 2008 are 40cm resolution color, and the 2010 are 10cm resolution
> color.
> 
> 
> ___
> 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

[Talk-ca] New Surrey Data

[Paul Norman]

Surrey has released 2010 Orthographs under PDDL in GeoTiff format. They're
at http://www.surrey.ca/city-services/4911.aspx

The images posted online have had their resolution reduced to approximately
40cm from 10cm for file-size reasons. Apparently the original GeoTiffs are
about 1 GB each. I'm talking to someone from the GIS department to see if I
can get the outlying areas or higher resolution images. Regardless, their
quality is higher than the previously posted 2008 orthographs.

I have been using the source values
source=City of Surrey 2010 Orthographs
source:url=http://www.surrey.ca/city-services/658.aspx

This may not be of interest to anyone else as I'm not sure if anyone else is
mapping in the Surrey area, but maybe it will inspire someone to. 


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

[Talk-ca] How to tag London Drugs?

[Paul Norman]

I've been working on tagging some stores, then I came across London Drugs.
For those who don't know, London Drugs is a store that sells electronics,
computers, cameras, homeware, health/wellness, beauty, food/candy, and also
has a pharmacy. In area, I'd estimate that it's about 1 part electronics, 1
part computers, 1 part cameras, 5 parts isles with other stuff, and 1 part
pharmacy. They're located in Western Canada.

Looking at the LD website and fliers, the focus is on electronics, cameras,
computers, and housewares. When people think of London Drugs they don't
think of a pharmacy initially.

Currently there are 29 POIs matching name=London Drugs in OSM. Of these
8 match amenity=pharmacy, of which one has shop=convenience;electronics and
one has shop=chemist
6 match shop=department_store
2 match shop=chemist, which is wrong as I believe all London drugs do
dispensing
2 match shop=supermarket, which is questionable as food is a small part of
their business

I believe the most appropriate tagging is shop=department_store but I'd like
the thoughts of others who have mapped them. The reasons why I believe it is
is that
- They market themselves as a department store, with little focus on their
pharmacy operations
- Unlike CVS in the US, when people hear London Drugs they don't necessarily
think of a pharmacy
- Current usage in OSM is inconclusive
- In mall directories they are listed alongside other major stores like
Sears and The Bay which are both clearly department stores.
- A number of stores have branched out into pharmacy operations, including
Safeway, but they're not pharmacies. 
- If enough detail is known, the pharmacy could be marked as a separate POI.
This is what the Lougheed Mall has done, listing both London Drugs and
London Drugs Pharmacy on their store list.

-- 
Paul Norman


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

Re: [Talk-ca] Hospital list...

[Paul Norman]

To get this info *out* of OSM you could use XAPI. A query like
 might work. The
wiki has more xapi documentation at http://wiki.openstreetmap.org/wiki/Xapi
which might help. You should be warned that xapi is at times slow and
outdated. You might also need to query building=hospital depending on how
people have tagged hospitals.

> -Original Message-
> From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-
> boun...@openstreetmap.org] On Behalf Of Colin McGregor
> Sent: Saturday, December 04, 2010 1:18 PM
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] Hospital list...
> 
> I am doing some stuff with the "Random Hacks of Kindness" folks
> (http://www.rhok.org/) and am looking for a list of geo-referenced
> hospitals. Anyone know an easy way to get this info. out of Open Street
> Map, or baring that know of another source of this data that could be
> freely re-used by not for profits looking to help co-ordinate disaster
> responses...
> 
> Thanks.
> 
> Colin McGregor
> 
> ___
> 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

[Talk-ca] Trans-Canada highway relations

[Paul Norman]

I have created new relations for the trans-canada highway on a per-province
basis (the same as US interstates are mapped) for SK and MB, and added a new
super-relation that 

If someone wants to continue this into Ontario it would be helpful. If
someone wants to help and just wants to let me know the routing of the
trans-canada through Ontario, I could do the work of the relations.

I'm also still cleaning up BC


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

[Talk-ca] Bing mis-alignment at UBC

[Paul Norman]

Just an FYI for anyone mapping at UBC - my measurements show that the bing
imagery is offset approximately 2m in the direction 150 degrees meaning
everything should be about 2m "north" of where you draw it based on bing,
where "north" follows the street direction.

I took the true position as canvec, which agrees with BC 1m orthos, and
other data sources.

This can be corrected with an offset with the JOSM imagery plugin of -2.5E-7
easting and 4.0E-7 northing

I confirmed this is approximately valid between Agronomy Road to Memorial
Road and Education Road almost to Wesbrook.




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

[Talk-ca] Proposed import: Surrey Address Data

[Paul Norman]

I'm proposing to import the surrey address data located at
http://www.surrey.ca/city-services/658.aspx

I've written a translation script for the data, and it, along with the data
untranslated and translated are located at
http://maps.paulnorman.ca/surrey/addresses/

Legal:

The data is PDDL, which is a well-known license and compatible.

Data quality: 

The data is essentially an export from the city's internal GIS server and
should be very accurate. I was unable to find any errors with spot checks.

With the exception of strip malls and townhouse complexes, the positions
seem very accurate. Strip malls are in order, but may not exactly match
store locations. Townhouses have similar issues. 

Size:
~100k nodes. This will need to be done in multiple parts on a separate
account.

Existing data:
A check with JOSM found no nodes with addr:* in Surrey

Shortfalls
- No postal codes
- Although the data is there for associated street relations, I'm not
proposing creating them

Sample node

addr:city=Surrey
addr:country=CA
addr:housenumber=11508
addr:state=British Columbia
addr:street=97A Avenue
source=City of Surrey 2010 GIS Data
source:url=http://www.surrey.ca/city-services/658.aspx
surrey:date=19850924=
surrey:globalid=E949685B-38B3-44D2-A5DC-C0750AE0B4C4


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

Re: [Talk-ca] Proposed import: Surrey Address Data

[Paul Norman]

I just wanted to note a couple of mistakes are present in the conversion of
rd -> road, etc, which are now fixed, and I'm re-running the conversions. 

> -Original Message-
> From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-
> boun...@openstreetmap.org] On Behalf Of Paul Norman
> Sent: Tuesday, January 04, 2011 12:52 AM
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] Proposed import: Surrey Address Data
> 
> I'm proposing to import the surrey address data located at
> http://www.surrey.ca/city-services/658.aspx
> 
> I've written a translation script for the data, and it, along with the
> data untranslated and translated are located at
> http://maps.paulnorman.ca/surrey/addresses/
> 
> Legal:
> 
> The data is PDDL, which is a well-known license and compatible.
> 
> Data quality:
> 
> The data is essentially an export from the city's internal GIS server
> and should be very accurate. I was unable to find any errors with spot
> checks.
> 
> With the exception of strip malls and townhouse complexes, the positions
> seem very accurate. Strip malls are in order, but may not exactly match
> store locations. Townhouses have similar issues.
> 
> Size:
> ~100k nodes. This will need to be done in multiple parts on a separate
> account.
> 
> Existing data:
> A check with JOSM found no nodes with addr:* in Surrey
> 
> Shortfalls
> - No postal codes
> - Although the data is there for associated street relations, I'm not
> proposing creating them
> 
> Sample node
> 
> addr:city=Surrey
> addr:country=CA
> addr:housenumber=11508
> addr:state=British Columbia
> addr:street=97A Avenue
> source=City of Surrey 2010 GIS Data
> source:url=http://www.surrey.ca/city-services/658.aspx
> surrey:date=19850924=
> surrey:globalid=E949685B-38B3-44D2-A5DC-C0750AE0B4C4
> 
> 
> ___
> 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

Re: [Talk-ca] Proposed import: Surrey Address Data

[Paul Norman]

I've done a test import of about 1k nodes for a few blocks, which can be
seen around
http://www.openstreetmap.org/?lat=49.180812&lon=-122.900047&zoom=18&layers=M

A few things I've noticed.
- Some houses are missing. These could be imported manually from the
"proposed" addresses
- The positioning is superb
- Surrey house numbers are long, and don't look great when they run together
on z17 with mapnik

At this point, I'd welcome any further feedback. As it happens, this area
was the toughest to get right because of all the "named" streets while most
of Surrey uses numbers

> -Original Message-
> From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-
> boun...@openstreetmap.org] On Behalf Of Paul Norman
> Sent: Tuesday, January 04, 2011 7:45 PM
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Proposed import: Surrey Address Data
> 
> I just wanted to note a couple of mistakes are present in the conversion
> of rd -> road, etc, which are now fixed, and I'm re-running the
> conversions.
> 
> > -Original Message-
> > From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-
> > boun...@openstreetmap.org] On Behalf Of Paul Norman
> > Sent: Tuesday, January 04, 2011 12:52 AM
> > To: talk-ca@openstreetmap.org
> > Subject: [Talk-ca] Proposed import: Surrey Address Data
> >
> > I'm proposing to import the surrey address data located at
> > http://www.surrey.ca/city-services/658.aspx
> >
> > I've written a translation script for the data, and it, along with the
> > data untranslated and translated are located at
> > http://maps.paulnorman.ca/surrey/addresses/
> >
> > Legal:
> >
> > The data is PDDL, which is a well-known license and compatible.
> >
> > Data quality:
> >
> > The data is essentially an export from the city's internal GIS server
> > and should be very accurate. I was unable to find any errors with spot
> > checks.
> >
> > With the exception of strip malls and townhouse complexes, the
> > positions seem very accurate. Strip malls are in order, but may not
> > exactly match store locations. Townhouses have similar issues.
> >
> > Size:
> > ~100k nodes. This will need to be done in multiple parts on a separate
> > account.
> >
> > Existing data:
> > A check with JOSM found no nodes with addr:* in Surrey
> >
> > Shortfalls
> > - No postal codes
> > - Although the data is there for associated street relations, I'm not
> > proposing creating them
> >
> > Sample node
> >
> > addr:city=Surrey
> > addr:country=CA
> > addr:housenumber=11508
> > addr:state=British Columbia
> > addr:street=97A Avenue
> > source=City of Surrey 2010 GIS Data
> > source:url=http://www.surrey.ca/city-services/658.aspx
> > surrey:date=19850924=
> > surrey:globalid=E949685B-38B3-44D2-A5DC-C0750AE0B4C4
> >
> >
> > ___
> > 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


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

[Talk-ca] Oneway=yes on NHN imported streams

[Paul Norman]

I noticed that the GeoBase waterways have oneway=yes on them, but are not
navigable so the one way access restrictions don't apply. I'm wondering, as
well as some others on IRC, how these came to be tagged that way. 


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

[Talk-ca] Proposed import: UBC Buildings

[Paul Norman]

I'm proposing to import the UBC buildings, available at
http://geodata.plantops.ubc.ca/data/OSM_Feb2011.zip

 

This import will be done carefully, comparing imported data with existing
data by hand, and may involve follow-up site surveys in case of conflicting
keys.

 

Legal:

The data is dual-licensed as CC-BY-SA and ODbl by UBC.

 

Tagging:

Buildings will be tagged with building=yes, name=(value of name_at),
ubc:building_num=(value of number), source=UBC Plant Ops 2011

 

Data quality:

The data agrees with bing aerial imagery, GPS traces, and BC Government
Openmaps imagery within the resolution of the imagery, after correcting for
building lean in the imagery.

 

The data is of *ground* level building outlines. The many overpasses will be
dealt with in the import process.

 

Import process:

The buildings will be compared with existing OSM data, and the way which
better represents the building will be kept. Tags will be merged, with any
conflicts followed up by a site survey as there are some disagreements about
names of minor buildings. Existing building entrances nodes will be merged
onto any new buildings, as with any connecting ways. It's a lot of work, but
the only way to get an import like this right.

 

Imports will be done from pnorman_imports

 

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

Re: [Talk-ca] Proposed import: UBC Buildings

[Paul Norman]

Whoops - sent my reply to myself, not the list

 

Based on the feedback from local mappers, I did a test into Hampton Place,
where there were no buildings before. This can be seen at
http://www.openstreetmap.org/?lat=49.257597
<http://www.openstreetmap.org/?lat=49.257597&lon=-123.234886&zoom=18&layers=
M> &lon=-123.234886&zoom=18&layers=M

 

A couple of thoughts

 

The roads here need verification. I didn't touch them except to get their
positioning right, but they need checking for names, access, etc. 

 

Some buildings that are in the shapefile didn't make it through ogr2osm. The
shapefile has a number of buildings with invalid geometries that it doesn't
like. 

 

A site survey is needed to do addr:* data, but I find this a lot easier to
do when I can print a map that has buildings and then write in each building
the details.

 

 

From: Paul Norman [mailto:penor...@mac.com] 
Sent: Saturday, February 05, 2011 3:29 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Proposed import: UBC Buildings

 

I'm proposing to import the UBC buildings, available at
http://geodata.plantops.ubc.ca/data/OSM_Feb2011.zip

 

This import will be done carefully, comparing imported data with existing
data by hand, and may involve follow-up site surveys in case of conflicting
keys.

 

Legal:

The data is dual-licensed as CC-BY-SA and ODbl by UBC.

 

Tagging:

Buildings will be tagged with building=yes, name=(value of name_at),
ubc:building_num=(value of number), source=UBC Plant Ops 2011

 

Data quality:

The data agrees with bing aerial imagery, GPS traces, and BC Government
Openmaps imagery within the resolution of the imagery, after correcting for
building lean in the imagery.

 

The data is of *ground* level building outlines. The many overpasses will be
dealt with in the import process.

 

Import process:

The buildings will be compared with existing OSM data, and the way which
better represents the building will be kept. Tags will be merged, with any
conflicts followed up by a site survey as there are some disagreements about
names of minor buildings. Existing building entrances nodes will be merged
onto any new buildings, as with any connecting ways. It's a lot of work, but
the only way to get an import like this right.

 

Imports will be done from pnorman_imports

 

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

[Talk-ca] Proposal: Cleanup of NHN ways in BC

[Paul Norman]

Lately I've been working on cleaning up the NHN rivers in the Seymour,
capilano, indian arm and a couple other watersheds. It occurs to me that
this is a process that needs to be done everywhere.

Existing tagging:
Currently there are two types of tagging for waterways that were imported.
The first of these is that for smaller waterways
accuracy:meters=10
attribution=Natural Resources Canada
oneway=yes
source=GeobaseNHN_Import_2009
waterway=stream
waterway:type=observed

The second is for "connector" waterways that are under lakes or rivers
accuracy:meters=-1
attribution=Natural Resources Canada
oneway=yes
source=GeobaseNHN_Import_2009
sub_sea=stream
sub_sea:type=inferred

The ways themselves are over-digitized, having approximately four times the
nodes they need to.

I propose the following process to clean up these ways. This is based on the
process I was manually using last week and it worked without needing any
corrections. 

1. Retag the connectors the same as streams, preserving any extra tags
(primarily name=*)
This subject came up on talk-us@

and the consensus was that they should be tagged like other waterways.
1b. Retag, moving accuracy:meters to accuracy, preserving attribution,
source, waterway, and removing waterway:type and oneway. Any waterways I
verify with imagery will have accuracy:meters removed and source set
appropriately. 

2. Stitch together ways of the same name into longer streams. This will take
the most time and intervention. At the same time, rivers will be changed
from waterway=stream to waterway=river

3. De-duplicate named streams and rivers. There is duplication between the
data that was imported and existing data from before the import that has not
been cleaned up, and at this stage it will be easy to identify and fix,
selecting one way based on imagery.

4. Run JOSM's simplify way function with max-error=2. This will remove
approximately 75% of the nodes from the streams while preserving the shape.
There are nodes every couple of meters, even for straight sections of river.

5. Break extremely long rivers into manageable sections. For obvious
reasons, I don't want to leave behind ways that stretch over hundreds of
kilometers like some of the rivers do. 

As a rough estimate, this will take an hour per NTS tile initially, with
most of that time being upload time. I think that right now there are more
nodes/square km in the middle of nowhere from the streams then in parts of
the lower mainland because the streams have excessive nodes.




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

Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC

[Paul Norman]

As an aside, the imports in the lower mainland were not done by Sam, but by
mbiker. I'm not sure on the exact import process used for the NRN data. If I
were to do the imports over again myself I think I'd use CanVec 7.0 which
seems to have the same data but I haven't evaluated it in any detail.

-Original Message-
From: Sam Vekemans [mailto:acrosscanadatra...@gmail.com] 
Sent: Tuesday, February 22, 2011 6:52 AM
To: Kevin Michael Smith; Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC

Cool, if i knew how to edit a stylesheet i would  :) So t hat's fine.


So perhaps then it can be all changed with a bot?


... or is it better to simply wipe my edits?



The rivers (without oneway=yes tag) is available in another api, so it's no
big deal.


cheers,
Sam


On 2/22/11, Kevin Michael Smith  wrote:
> On Tue, 2011-02-22 at 06:34 -0800, Sam Vekemans wrote:
>> Great! Were getting somewhere..
>>
>>
>> Now lets discuss the most appropriate tag that can be used to 
>> indicate the rendering of a flow line arrow.
>
> It's not about tagging the rivers to say 'there should be an arrow 
> here', it's about putting 'Rivers have arrows' in the style sheet for
> the renderer.   'Having arrows' isn't a property of the river, it's a
> property of how we may or may not want to display it.
>
> --
> Kevin Michael Smith 
>


--
Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room)
@Acrosscanadatrails

___
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

Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC

[Paul Norman]

Thanks for the background - that explains why some things are the way they
are and some of the oddities. 

For connector ways, I'd estimate that 95% of them are for very small bodies
of water without names or for rivers, where it does make sense to talk about
the river flowing through. For the relatively rare case of a large body of
water I could then revert it to sub_sea=*

A typical example of a connector waterway is
http://www.openstreetmap.org/browse/way/72831492

NHN had no ways tagged as waterway=river, all the rivers were tagged as
waterway=stream or sub_sea=stream. An example of this is the Indian River,
which was tagged as sub_sea for approximately 20 km and then was a mix of
sub_sea=stream and waterway=stream for the remainder.

I've found Bing's imagery in rural areas is often the same as that on the BC
openmaps server and very accurately aligned, so I was planning on using
Bing. Attribution will be preserved

Anyways, back to the concerns about connector waterways. What would you
think about if I added in with step 5 reverting sections of waterways under
large lakes to sub_sea?

I know that after doing all of these steps that some waterways may be
mistagged, but it should be significantly fewer than currently and after
simplification and joining named ways together it should be easier to go in
and edit.



> -Original Message-
> From: Adam Dunn [mailto:dunna...@gmail.com]
> Sent: Tuesday, February 22, 2011 9:38 AM
> To: Paul Norman
> Cc: Talk-CA OpenStreetMap
> Subject: Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC
> 
> Right, the NHN import in the area mentioned was done by MBiker. MBiker
> was a pretty big mapper for the Vancouver area. He started off doing
> lots of manual edits by biking around and gps'ing, then he got involved
> in the NRN road import for east GVRD, then he did NHN for the entire
> watershed area (08X-something?). The problem with his NHN import was
> that he bit off more than he could chew. He was going around fixing and
> cleaning the NHN stuff he imported (like a good importer should do), but
> he suddenly stopped working on OSM in October. I think maybe the size of
> the import was too daunting for one man?
> 
> The process used for importing NHN was different depending on how much
> was being imported at once. When an entire watershed was done (which is
> the case here), it was:
> 1. Download NHN watershed in .osm format from Yan's server.
> 2. Use one of the bulk upload scripts.
> 3. Download area from OSM with JOSM and fix any issues.
> 
> For BC non-coastal watersheds, Canvec is equal to NHN. There was an
> issue with watersheds abutting against the coast, but I can't remember
> if this was resolved (and a quick search through my email history turns
> up nothing).
> 
> Sam's purpose of the oneway=yes tag was twofold: to get waterflow
> direction arrows to render, and to show that the flow direction was
> verified (could have used a "direction_verified=yes" tag). This goes
> against the standard for OSM tagging of waterways, since the direction
> of the way itself implies waterflow direction. Mapnik doesn't render
> flow direction, but that's a matter of the renderer, not the data, just
> like Richard said.
> 
> I don't think Sam's (or MBiker's) imports need to be wiped, since that
> would mean a couple months from now someone will just do the same thing
> from Canvec. Or if you are anti-import, you can delete the data, put on
> some bug spray and hiking boots and go map the streams yourself.
> 
> Now to get back to the original question.
> 
> I disagree that connectors should be upgraded to stream. On the talk-us
> list, they gave the example of a river still running through a man-made
> reservoir, so upgrading to stream would be okay, but in most cases, I
> don't think it would be appropriate. I think it would be incorrect to
> think that Chilliwack River flows underneath Chilliwack Lake or Sweltzer
> River flows through Cultus Lake. In most cases they shouldn't be
> rendered, since it only makes sense to have the lake rendered. It's not
> just a rendering issue though, I think connectors are logically
> different from normal waterways. The purpose of the connector ways (as
> far as I can think of) is for topological reasons.
> It's useful to see how different streams and rivers flow through lakes,
> and how they are connected to each other. We could ask, for example,
> "can a fish swim from Cultus Lake to Chilliwack Lake", or "if ammonium
> chloride spills into Slesse Creek, where will it end up?".
> This is why the connector ways are present. You could potentially make a
> script that analyzes inflowing and outflowing waterways connected to a
> lake, and make

Re: [Talk-ca] Secret routing demo.

[Paul Norman]

I think I have a note somewhere that says "This is confusing in OSM. It's
worse on the ground". I try to include those when I map something that seems
completely illogical, but is an accurate representation of reality.

I fixed the Brunette/Bernatchey intersection - my imagery indicates that you
can't get to that from the service lane, so you can't go from the middle of
the H to westbound brunette and there's not enough room to do a u-turn.

I also fixed up my UBC commute - unfortunately, the
secondary/tertiary/primary designations don't mean as much in the city for
travel time as the router thinks. It gets the work commute exactly right, in
both directions.

> -Original Message-
> From: Adam Dunn [mailto:dunna...@gmail.com]
> Sent: Saturday, March 05, 2011 10:03 PM
> To: talk-ca
> Subject: Re: [Talk-ca] Secret routing demo.
> 
> In Vancouver, from Hwy 1 heading west onto Brunette Ave heading
> southwest, the routing software advises to take the offramp going north
> onto Brunette, then do a u-turn at the Brunette/Bernatchey intersection
> in order to head south on Brunette. However, if one were to continue
> along Hwy 1, there is a proper offramp to go south on Brunette. Judging
> by the map, it looks like the u-turn method is actually shorter in terms
> of distance, so this is what the routing software chooses to do! (plus
> the Brunette/Bernatchey intersection is an H style [Brunette being the
> dual-way], so the software doesn't see it as a u-turn). A no_u_turn
> relation would fix this issue, but I'm not sure if u-turns are actually
> restricted there.
> 
> Also, the routing software attempts to use ferries if it needs to, but
> doesn't seem to be using the Horseshoe Bay (Vancouver) <-> Departure Bay
> (Nanaimo) route even though it all seems okay in data.
> 
> Adam
> 
> P.S. pnorman is my hero for the following tag: note=Yes, this track does
> overlap a road It's nice when people explain their odd ways of mapping
> (a rail and a road overlapping ways in this case).
> 
> On Sat, Mar 5, 2011 at 8:36 PM, James Ewen  wrote:
> > Section of highway 2 southbound immediately south of the Anthony
> > Henday was one way northbound not allowing anyone to leave the city of
> > Edmonton! Reversed the flow!
> >
> > James
> > VE6SRV
> >
> > ___
> > 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


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

Re: [Talk-ca] Importing MLI park boundaries

[Paul Norman]

I prefer http://wiki.openstreetmap.org/wiki/Ogr2osm to do the conversions.
To convert you have to write a python function that maps the shapefile
tagging to osm tagging. This is not technically very hard, but mapping to
osm tags is very easy to get wrong.

If you're using Windows, I'd suggest using VirtualBox and Ubuntu to run it. 

> -Original Message-
> From: Samuel Dyck [mailto:samueld...@gmail.com]
> Sent: Friday, March 25, 2011 12:12 PM
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] Importing MLI park boundaries
> 
> Hi Everyone
> 
> The Canvec data for MB provincial park boundaries is horribly inaccurate
> and this bothers me greatly. The government of Manitoba offers good
> boundary data and a bunch of other cool stuff though the Manitoba Lands
> Initiative, which I believe we can use, but I've never converted
> Shapefiles to an API 0.6 compatible osm file (or at all really). How
> would I best do this?
> 
> Sam Dyck
> 
> ___
> 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

Re: [Talk-ca] Importing MLI park boundaries

[Paul Norman]

I'd suggest doing a conversion and posting a .osm file somewhere so we can
see the proposed tagging. 

> -Original Message-
> From: Samuel Dyck [mailto:samueld...@gmail.com]
> Sent: Friday, March 25, 2011 7:40 PM
> To: Paul Norman
> Cc: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Importing MLI park boundaries
> 
> I'm using an Ubuntu derived distro, so I should be good. Tyler converted
> the MLI building data and has been importing it into OSM already. I've
> read thought the terms, do I need to clear a import with someone?
> 
> Sam
> 
> 
> 
> On 11-03-25 03:32 PM, Paul Norman wrote:
> > I prefer http://wiki.openstreetmap.org/wiki/Ogr2osm to do the
> conversions.
> > To convert you have to write a python function that maps the shapefile
> > tagging to osm tagging. This is not technically very hard, but mapping
> > to osm tags is very easy to get wrong.
> >
> > If you're using Windows, I'd suggest using VirtualBox and Ubuntu to
> run it.
> >
> >> -Original Message-
> >> From: Samuel Dyck [mailto:samueld...@gmail.com]
> >> Sent: Friday, March 25, 2011 12:12 PM
> >> To: talk-ca@openstreetmap.org
> >> Subject: [Talk-ca] Importing MLI park boundaries
> >>
> >> Hi Everyone
> >>
> >> The Canvec data for MB provincial park boundaries is horribly
> >> inaccurate and this bothers me greatly. The government of Manitoba
> >> offers good boundary data and a bunch of other cool stuff though the
> >> Manitoba Lands Initiative, which I believe we can use, but I've never
> >> converted Shapefiles to an API 0.6 compatible osm file (or at all
> >> really). How would I best do this?
> >>
> >> Sam Dyck
> >>
> >> ___
> >> 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

Re: [Talk-ca] Importing MLI park boundaries

[Paul Norman]

The other information of note is that Sam did not remove his release to PD
until Febuary 2011.[1] My interpretation would be that any changeset
uploaded by him in this time is released into the public domain.

Therefore, it'd be acceptable to re-import any of his changesets as they are
public domain. It's not possible to just undo a PD grant.

http://wiki.openstreetmap.org/w/index.php?title=User:Acrosscanadatrails&oldi
d=553498#License_Issue

> -Original Message-
> From: Richard Weait [mailto:rich...@weait.com]
> Sent: Saturday, March 26, 2011 11:36 AM
> To: Sam Vekemans
> Cc: d...@osmfoundation.org; board Board; Talk-CA OpenStreetMap
> Subject: Re: [Talk-ca] Importing MLI park boundaries
> 
> Re: On 25 August 2010, Sam Vekemans said on his wiki user page, "All my
> contributions to OpenStreetMap are released into the public domain... I
> grant anyone the right to use my contributions for any purpose"  [1]
> 
> [1]
> http://wiki.openstreetmap.org/w/index.php?title=User:Acrosscanadatrails&;
> oldid=522835#License_Issue
> 
> On Sat, Mar 26, 2011 at 1:45 PM, Sam Vekemans
>  wrote:
> > Lol, that page is no longer valid.
> 
> "No longer valid"?  You said it.  Did you mean that when you said it?
> 
> ___
> 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

[Talk-ca] Proposed import of IBC data (was RE: NAD83-SCRS vs WGS84 Reference systems)

[Paul Norman]

Adding talk-us@ and imports@ to the cc list since this touches the border.

The IBC data matches decently with the NAIP and Bing imagery on the border,
and very well with my 10cm Surrey imagery. The existing border data in OSM
is about 20m away in parts (near monument 32 for example)

The proposed tagging is
man_made=survey_point
ref=32
source=CA-US International Boundary Commission

I don't think it's worth the effort to worry about any NAD83-CSRS vs. WGS84
differences.

I've uploaded a sample at http://maps.paulnorman.ca/49th.osm


> -Original Message-
> From: Richard Weait [mailto:rich...@weait.com]
> Sent: Sunday, March 27, 2011 6:22 AM
> To: Daniel Begin
> Cc: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] NAD83-SCRS vs WGS84 Reference systems
> 
> On Sat, Mar 26, 2011 at 3:55 PM, Daniel Begin 
> wrote:
> > Hi all,
> >
> > I need someone to confirm the following about reference system...
> >
> > Context: Paul and I are uploading US-Canada boundary monuments/turning
> > points to get a stable and verifiable information. The data is
> > available from their web site and I got the confirmation that the data
> > can be used without any restriction.  The data can be found here...
> > http://www.internationalboundarycommission.org/products.html
> >
> > and it is available for NAD27 and NAD83-SCRS reference system.
> >
> > Context: For what I understand, The difference between NAD83-SCRS and
> > WGS84 is 0-2 meters.  To get a rigorous transformation from NAD83-SCRS
> > to WGS84 we need to use shift grids describing the shift between NAD83
> and NAD83-SCRS.
> > These grids should be available through provincial agencies but I have
> > been told that not all provinces have them available.
> >
> > Question1: Do I understand it properly?
> >
> > Question2: Considering that provided coordinates value/reference
> > numbers can be read directly from their web site, it make sense for me
> > to use NAD83-SCRS directly even if there is a 0-2 meter offset.  Does
> > it make sense for everyone?
> 
> Bonjour Daniel!
> 
> We do have others on this list with experience in re-projection.  I hope
> they'll join in.
> 
> I've asked about the shift grids on #osm-dev.
> 
> If I remember correctly, the current Can-US border came from IBC data.
>  How does the current border line match the monument data that you are
> considering?  Should they be identical and are they?  Could we pop this
> data into a tile overlay layer so we can look at it on existing OSM data
> (without the import)?
> 
> Best regards,
> Richard
> 
> ___
> 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

Re: [Talk-ca] [Talk-us] Proposed import of IBC data (was RE: NAD83-SCRS vs WGS84 Reference systems)

[Paul Norman]

For the area here, they appear to all have monuments or the imagery is of
insufficient quality to determine. What's the difference between a survey
point and a turning point? Is it that one has a small change in direction
while the other has a large change in direction? 

For the 49th parallel, all of the monuments are of the form Mon xx or Mon.
xx

For the other regions, I see some are of the form TP xx.

I don't think survey_point=turning_point is what we should use.
http://taginfo.openstreetmap.de/keys/survey_point#values shows that it's
mainly used to indicate the physical form of the survey point. 

> -Original Message-
> From: Richard Weait [mailto:rich...@weait.com]
> Sent: Sunday, March 27, 2011 1:46 PM
> To: Daniel Begin
> Cc: impo...@openstreetmap.org; talk...@openstreetmap.org; Paul Norman;
> talk-ca@openstreetmap.org
> Subject: Re: [Talk-us] Proposed import of IBC data (was RE: [Talk-ca]
> NAD83-SCRS vs WGS84 Reference systems)
> 
> On Sun, Mar 27, 2011 at 4:40 PM, Daniel Begin 
> wrote:
> > Thank Paul, a really good idea to include others as they are concerned
> > :-)
> >
> > About tagging, I would agree with minor adjustments ...
> > man_made=survey_point - agreed
> >
> > ref= - agreed to reference a monument id However, I would add a
> > prefix for turning points, helping differentiate them from monuments.
> > I propose the prefix "tp ": ref=tp 123
> 
> I'd prefer to see values without spaces, for ease of consuming
> downstream.  Does the source distinguish between monuments and turning
> points?  If not, perhaps following their lead makes sense by using their
> ref=123, and adding something like survey_point=turning_point, or
> similar?
> 



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

[Talk-ca] Data Source for Surrey Roads

[Paul Norman]

I just finished converting the Surrey road data to a .osm file. This may be
of interest to anyone mapping in the Surrey area.

I've posted it to http://maps.paulnorman.ca/surrey/SurreyRoads2010.zip along
with the ogr2osm translation file I wrote.

I'm not planning to import it wholesale, just selectively if I have to
update a road, and I plan to move some tags over on major roads (maxspeed,
lanes, hgv=*, hazmat=*)

Some notes on the strengths and weakness of the data

Weaknesses:
- Ways are not dualized. This road data was intended for their printed maps
which do not have dualized roads. Incidentally, I purchased one of those
maps.

- Some roads are off in position. Most are extremely good with <40cm error,
but some have jogs that are out of place by a few meters. 

- Odd classifications. Some roads are classified strangely. This only
impacts secondary and primary roads.

Strengths:

- It is very recent, with roads not constructed until late 2010 present in
the data

- The postions seem slightly better than GeoBase

- It has truck access and hazardous material restrictions

- It has speed and lane information


The tagging of a typical road is

highway=residential
lanes=2
maxspeed=50
name=58 Avenue
source=City of Surrey 2010 GIS Data
surface=Asphalt
surrey:geodb_oid:496

while a highway looks like

hazmat=designated
hgv=designated
highway=primary
etc.


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

Re: [Talk-ca] Data Source for Surrey Roads

[Paul Norman]

PDDL - essentially public domain. Surrey makes their data available at
http://www.surrey.ca/city-services/658.aspx and the roads data is found as
trnRoadCentrelines in SurreyProperty or SurreyTransportation. Surrey really
seems to get open data. They make their data available under open terms and
provide lots of detail in their shapefiles, and let the users decide what to
do.


> -Original Message-
> From: Corey Burger [mailto:corey.bur...@gmail.com]
> Subject: Re: [Talk-ca] Data Source for Surrey Roads
> 
> Nifty stuff. My one concern is with the license. What is the license
> behind this data?
> 
> Corey
> 
> On Mon, Mar 28, 2011 at 4:43 PM, Paul Norman  wrote:
> > I just finished converting the Surrey road data to a .osm file. This
> > may be of interest to anyone mapping in the Surrey area.
> >
> > I've posted it to http://maps.paulnorman.ca/surrey/SurreyRoads2010.zip
> > along with the ogr2osm translation file I wrote.
> >
> > I'm not planning to import it wholesale, just selectively if I have to
> > update a road, and I plan to move some tags over on major roads
> > (maxspeed, lanes, hgv=*, hazmat=*)
> >
> > Some notes on the strengths and weakness of the data
> >
> > Weaknesses:
> > - Ways are not dualized. This road data was intended for their printed
> > maps which do not have dualized roads. Incidentally, I purchased one
> > of those maps.
> >
> > - Some roads are off in position. Most are extremely good with <40cm
> > error, but some have jogs that are out of place by a few meters.
> >
> > - Odd classifications. Some roads are classified strangely. This only
> > impacts secondary and primary roads.
> >
> > Strengths:
> >
> > - It is very recent, with roads not constructed until late 2010
> > present in the data
> >
> > - The postions seem slightly better than GeoBase
> >
> > - It has truck access and hazardous material restrictions
> >
> > - It has speed and lane information
> >
> >
> > The tagging of a typical road is
> >
> > highway=residential
> > lanes=2
> > maxspeed=50
> > name=58 Avenue
> > source=City of Surrey 2010 GIS Data
> > surface=Asphalt
> > surrey:geodb_oid:496
> >
> > while a highway looks like
> >
> > hazmat=designated
> > hgv=designated
> > highway=primary
> > etc.
> >
> >
> > ___
> > 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

[Talk-ca] Proposed import: Surrey, BC waterways

[Paul Norman]

In short, the waterways in Surrey BC are largely from NHN data which in some
cases is accurate, but tends to be 20-30 years old. I'm proposing importing
data from the city, licensed under PDDL. I'm at least 2-3 weeks away from
being ready to do the import as I have some other priorities currently but I
wanted to get feedback.

I see this import as fixing two problems. The first is the old NHN data. The
second is the high number of unmapped ditches in Surrey. Because of the
nature of the soil, it is very common for houses to have drainage ditches in
front of them. These are largely unmapped, but the shapefiles appear to have
all ditches.

Legal: The data is licensed under PDDL, a compatible license.
Accuracy: The positioning is very good. 
Completeness: Not all culverts are mapped. Random checks revealed no missing
ditches or streams.
Existing data: It was all mapped by me or imported. I am proposing removing
it.

There are more details at
http://wiki.openstreetmap.org/wiki/Canada:British_Columbia:Vancouver/Imports
/Surrey/Waterways about the exact tagging. I intend to refine this, but this
may require a couple of site surveys. Before importing I will post a sample
.osm file for review.


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

Re: [Talk-ca] [Imports] Proposed import: Surrey, BC waterways

[Paul Norman]

> From: Richard Weait [mailto:rich...@weait.com]
> 
> On Tue, Mar 29, 2011 at 2:31 AM, Paul Norman  wrote:
> > In short, the waterways in Surrey BC are largely from NHN data which
> > in some cases is accurate, but tends to be 20-30 years old. I'm
> > proposing importing data from the city, licensed under PDDL. I'm at
> > least 2-3 weeks away from being ready to do the import as I have some
> > other priorities currently but I wanted to get feedback.
> >
> > I see this import as fixing two problems. The first is the old NHN
> > data. The second is the high number of unmapped ditches in Surrey.
> > Because of the nature of the soil, it is very common for houses to
> > have drainage ditches in front of them. These are largely unmapped,
> > but the shapefiles appear to have all ditches.
> >
> > Legal: The data is licensed under PDDL, a compatible license.
> > Accuracy: The positioning is very good.
> > Completeness: Not all culverts are mapped. Random checks revealed no
> > missing ditches or streams.
> > Existing data: It was all mapped by me or imported. I am proposing
> > removing it.
> >
> > There are more details at
> > http://wiki.openstreetmap.org/wiki/Canada:British_Columbia:Vancouver/I
> > mports /Surrey/Waterways about the exact tagging. I intend to refine
> > this, but this may require a couple of site surveys. Before importing
> > I will post a sample .osm file for review.
> 
> I think that the Surrey, BC data under PDDL is wonderful.  And I know
> that you have previously looked at their address data and road data and
> found it very helpful with addr:, maxspeed and hgv information.

This data is more controversial, which is why I'm asking for feedback early
in the process. 

> 
> I wonder if these common roadside ditches will share the same drawbacks
> as sidewalks in some other areas.  In fact, if sidewalks exist in this
> area as well, the ditches may compound the problems of sidewalks.  In
> summary portions of the OSM community are divided about sidewalks.  Some
> feel that mapping sidewalks isn't needed where they are common.  If all
> roads have sidewalks, why map them separately?
> Others feel that sidewalks should be indicated as tags on roads, like
> sidewalk=both for both sides.  Others feel that mapping each sidewalk
> with a separate highway=footway way adds important detail to the map for
> pedestrians.  Still others find that editing an area with a substantial
> number of separate sidewalk ways makes editing more difficult;  smaller
> download areas are permitted, editing the shape of a road means editing
> the shape of two sidewalks as well, adding other objects like building
> and POI have additional ways to "snap to"
> unintentionally.

Good points. If we decide against importing the ditch data, I can rework the
files to only include streams and named ditches. 

I think the ditches are worth mapping. The ditches in question are typically
2-5m wide and can be seen on imagery. 

They have culverts to allow foot and vehicle traffic to pass over them. I
view them in many ways as analogous to fences on private property which are
often mapped. Like fences, they are physical features which are significant
if crossing, but placed in a way that doesn't impact most foot traffic.

The shapefiles can be broken down into 4 relevant groups of ways.

The first of these is streams. These typically meander, are in forested
areas, are natural as opposed to constructed, and often have names. In my
view, these are definitely worth importing.

The second of these is ditches in rural and agricultural areas. These are
relatively long with unbroken stretches. They sometimes have breaks where
they go into culverts to go under roads or footways. These are also worth
importing, but hard to distinguish from the third category.

The third is ditches in suburban areas. These are used for drainage. They
are 2-5m wide, and frequently broken by culverts. They go around blocks
often and don't cross under roads. They eventually drain into the storm
drain system. This is what the debate should be about. I feel they're worth
mapping as they are significant physical features.

The ditches are not found everywhere, I found them mainly in areas
constructed in what was damp soil in the 1970-1990s.

The fourth is culverts. They come from a separate shapefile and join the
breaks in the above classes.

> A road with two  sidewalks and two ditches sounds like a further
> complication.  There would then be five ways for each road?  Perhaps
> mapping each ditch, where they are common is over the line towards
> photo-realism or "micro-mapping" in my book.

The ditches are typically in areas without sidewalks. 

> 
> Would these ditches then 

Re: [Talk-ca] [Imports] Proposed import: Surrey, BC waterways

[Paul Norman]

I've rendered an area locally at
http://maps.paulnorman.ca/surreywater.html?bbox=-122.88,49.08,-122.82,49.12

This is OSM data + drains + streams. Culverts are not included. There is
some overlap between NHN and Surrey data which would not be present in the
import.

An example of the worst case for waterways is can be found in Bridgeview at 
http://maps.paulnorman.ca/surreywater.html?bbox=-122.8773,49.2068,-122.8680,
49.2108

Hopefully this will help with determining if we want the roadside ditch
information.

> From: Paul Norman [mailto:penor...@mac.com]
> Subject: Re: [Talk-ca] [Imports] Proposed import: Surrey, BC waterways
> 
> > From: Richard Weait [mailto:rich...@weait.com]
> >
> > On Tue, Mar 29, 2011 at 2:31 AM, Paul Norman  wrote:
> > > In short, the waterways in Surrey BC are largely from NHN data which
> > > in some cases is accurate, but tends to be 20-30 years old. I'm
> > > proposing importing data from the city, licensed under PDDL. I'm at
> > > least 2-3 weeks away from being ready to do the import as I have
> > > some other priorities currently but I wanted to get feedback.
> > >
> > > I see this import as fixing two problems. The first is the old NHN
> > > data. The second is the high number of unmapped ditches in Surrey.
> > > Because of the nature of the soil, it is very common for houses to
> > > have drainage ditches in front of them. These are largely unmapped,
> > > but the shapefiles appear to have all ditches.
> > >
> > > Legal: The data is licensed under PDDL, a compatible license.
> > > Accuracy: The positioning is very good.
> > > Completeness: Not all culverts are mapped. Random checks revealed no
> > > missing ditches or streams.
> > > Existing data: It was all mapped by me or imported. I am proposing
> > > removing it.
> > >
> > > There are more details at
> > > http://wiki.openstreetmap.org/wiki/Canada:British_Columbia:Vancouver
> > > /I mports /Surrey/Waterways about the exact tagging. I intend to
> > > refine this, but this may require a couple of site surveys. Before
> > > importing I will post a sample .osm file for review.
> >
> > I think that the Surrey, BC data under PDDL is wonderful.  And I know
> > that you have previously looked at their address data and road data
> > and found it very helpful with addr:, maxspeed and hgv information.
> 
> This data is more controversial, which is why I'm asking for feedback
> early in the process.
> 
> >
> > I wonder if these common roadside ditches will share the same
> > drawbacks as sidewalks in some other areas.  In fact, if sidewalks
> > exist in this area as well, the ditches may compound the problems of
> > sidewalks.  In summary portions of the OSM community are divided about
> > sidewalks.  Some feel that mapping sidewalks isn't needed where they
> > are common.  If all roads have sidewalks, why map them separately?
> > Others feel that sidewalks should be indicated as tags on roads, like
> > sidewalk=both for both sides.  Others feel that mapping each sidewalk
> > with a separate highway=footway way adds important detail to the map
> > for pedestrians.  Still others find that editing an area with a
> > substantial number of separate sidewalk ways makes editing more
> > difficult;  smaller download areas are permitted, editing the shape of
> > a road means editing the shape of two sidewalks as well, adding other
> > objects like building and POI have additional ways to "snap to"
> > unintentionally.
> 
> Good points. If we decide against importing the ditch data, I can rework
> the files to only include streams and named ditches.
> 
> I think the ditches are worth mapping. The ditches in question are
> typically 2-5m wide and can be seen on imagery.
> 
> They have culverts to allow foot and vehicle traffic to pass over them.
> I view them in many ways as analogous to fences on private property
> which are often mapped. Like fences, they are physical features which
> are significant if crossing, but placed in a way that doesn't impact
> most foot traffic.
> 
> The shapefiles can be broken down into 4 relevant groups of ways.
> 
> The first of these is streams. These typically meander, are in forested
> areas, are natural as opposed to constructed, and often have names. In
> my view, these are definitely worth importing.
> 
> The second of these is ditches in rural and agricultural areas. These
> are relatively long with unbroken stretches. They sometimes have breaks
> where they go into culverts to go under roads or footways. These are
> also wo

[Talk-ca] New Background layers for Surrey

[Paul Norman]

I've developed a couple of new layers that I use as background layers when
working in Surrey, BC. First off though, do NOT import these files. Instead,
merge objects from them or trace from them if you want to use them.

 

The first is cadLotsSHP, the Surrey castradal data. Castradal data (property
lot data) is not suitable for importing into OSM, but there are uses.
Included in it is school and park data as well as some railway landuse data.
It is also sometimes useful for establishing the bounds of residential
areas. An example of this is http://www.openstreetmap.org/?minlon=-122.868
 &minlat=49.126&maxlon=-122.862&maxlat=49.134&box=yes
where I used the outer lots to establish the landuse for the block.

 

The second is parkNaturalAreasSHP, which is a map of natural areas in parks.
I describe this conversion in detail at
http://www.paulnorman.ca/blog/2011/04/a-simpler-shapefile-conversion/ but
basically everything is natural=wood wood=coniferous/deciduous/mixed,
natural=scrub or landuse=meadow.

 

The third is trnRoadCentrelinesSHP which is the Surrey road network data
which I posted to talk-ca@ earlier. I've been using it for fixing
abbreviated road names (e.g. 22 av instead of 22B Avenue) as well as adding
in maxspeed=* lanes=* information for major roads.

 

My typical workflow with these files is I have them up in the background and
instead of tracing, I merge the relevant object to the OSM layer. The end
result is the same, but I find it faster.

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

Re: [Talk-ca] New Background layers for Surrey

[Paul Norman]

And I suppose it would be helpful if I linked to the file I meant to.

http://maps.paulnorman.ca/surrey/SurreyDataJan11.zip

 

 

From: Paul Norman [mailto:penor...@mac.com] 
Sent: Wednesday, April 06, 2011 9:20 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] New Background layers for Surrey

 

I've developed a couple of new layers that I use as background layers when
working in Surrey, BC. First off though, do NOT import these files. Instead,
merge objects from them or trace from them if you want to use them.

 

The first is cadLotsSHP, the Surrey castradal data. Castradal data (property
lot data) is not suitable for importing into OSM, but there are uses.
Included in it is school and park data as well as some railway landuse data.
It is also sometimes useful for establishing the bounds of residential
areas. An example of this is http://www.openstreetmap.org/?minlon=-122.868
<http://www.openstreetmap.org/?minlon=-122.868&minlat=49.126&maxlon=-122.862
&maxlat=49.134&box=yes> &minlat=49.126&maxlon=-122.862&maxlat=49.134&box=yes
where I used the outer lots to establish the landuse for the block.

 

The second is parkNaturalAreasSHP, which is a map of natural areas in parks.
I describe this conversion in detail at
http://www.paulnorman.ca/blog/2011/04/a-simpler-shapefile-conversion/ but
basically everything is natural=wood wood=coniferous/deciduous/mixed,
natural=scrub or landuse=meadow.

 

The third is trnRoadCentrelinesSHP which is the Surrey road network data
which I posted to talk-ca@ earlier. I've been using it for fixing
abbreviated road names (e.g. 22 av instead of 22B Avenue) as well as adding
in maxspeed=* lanes=* information for major roads.

 

My typical workflow with these files is I have them up in the background and
instead of tracing, I merge the relevant object to the OSM layer. The end
result is the same, but I find it faster.

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

[Talk-ca] Township of Langley goes open

[Paul Norman]

The Township of Langley has released a number of data sets under the PDDL, a
license that is compatible with OSM, at
http://www.tol.ca/ServicesContact/OpenData/OpenDataCatalogue.aspx

 

They have released about 40 datasets which I will be looking at after my
exams to see what has usable data. A quick look shows that there are some
datasets  which have information which would be worth importing. The OSM
data is superior in some areas so any imports will have to be done carefully
to not overwrite existing data. The most interesting datasets appear to be
the trails and parks ones. The OSM data is good, but I see them as a way to
identify additional trails and parks which aren't mapped.

 

I'm also willing to collect any comments about the data and forward them on
to the GIS department. If anyone else is interested on working on this, let
me know and we can coordinate.

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

Re: [Talk-ca] NTS tile 040P

[Paul Norman]

> From: James A. Treacy [mailto:tre...@debian.org]
> Sent: Tuesday, June 07, 2011 1:06 PM
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] NTS tile 040P
> 
> Hello,
> I believe I am looking for a subtile of 040P but the directory
> ftp://ftp2.cits.rncan.gc.ca/osm/pub/040/P/ is empty.
> 
> This brings up a related point:
> Is there a web page that makes it easy to find the tile you want?
> A mashup would be ideal.

I personally use a poster sized NTS map of BC to identify tiles and a sheet
of plastic over top of it to write notes as I import, but it'd be nice
having a map with at least basic features (rivers, lakes) with a NTS
overlay.

I also have a poster sized map of the city with a grid on it for when I have
to systematically do something to the entire city area by area.


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

Re: [Talk-ca] GeoTiff in JOSM

[Paul Norman]

Two options

1. Covert to tiles with gdal2tiles or another program.
2. Set up MapServer and server it with WMS

1 is faster at serving tiles but takes more disk space and pre-processing. 2
is slower but better for large files since you don't have to pre-process.

As your GeoTiff isn't very large, the first is a viable option. I'd guess it
might take me a week to process. 

MapServer is a pain to set up, as you've discovered. If you're running
Ubuntu I could show you my .map file if it'd help.



> -Original Message-
> From: Tyler Gunn [mailto:ty...@egunn.com]
> Sent: Tuesday, August 30, 2011 6:46 PM
> To: Talk-CA OpenStreetMap
> Subject: [Talk-ca] GeoTiff in JOSM
> 
> Anyone have a hint of how to view a GeoTiff in JOSM?
> Manitoba Lands Initiative updated the aerial imagery of Winnipeg and has
> a 50cm res MrSid file of the Winnipeg capital region; much more up to
> date than Bing aerial and also including high res pics of areas that
> Bing doesn't have.
> I've converted the MrSid file to a tiled GeoTiff, but at 19GB in size I
> am thinking I'll need to serve it up some how.
> I'm thinking I may need to use MapServer to serve this as a WMS layer
> for JOSM, but I'm not finding decent how-tos on that.
> Any hints?
> Thanks!
> 
> ___
> 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

Re: [Talk-ca] Visit Vancouver in 7 Sep

[Paul Norman]

I should be free tomorrow evening - I only have a morning class.

> -Original Message-
> From: Adam Dunn [mailto:dunna...@gmail.com]
> Sent: Monday, September 05, 2011 8:57 PM
> To: Hiroshi Miura
> Cc: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Visit Vancouver in 7 Sep
> 
> I may be making the 2 hour trip from my home in Chilliwack into
> Vancouver that day, so I might see you there. All depends on other
> factors though, so no guarantees.
> 
> Adam
> 
> On Mon, Sep 5, 2011 at 7:30 PM, Hiroshi Miura  wrote:
> > Hi Canadian mappers!
> >
> > I'm Hiroshi Miura, A Japanese mapper and leader of OSM Japan.
> >
> > I have a plan to visit Vancouver BC. on the way to State of the Map
> > 2011 in Denver!
> > I'll arrive at noon in 7th Sep, tomorrow.
> >
> > Sorry for short notice.
> >
> > It is just 1 day transit, but I wanna enjoy downtown Vancouver with
> > POI mapping, walking and tasty beer & seafoods.
> >
> > If anyone is interested in talking with me in evening 7 sep., please
> > contact me on tw, fb or osm message.
> >
> >
> > #You may also be interested in our Ushahidi project:
> > http://sinsai.info/ #and its blog in English:
> > http://sinsai-info-en.blogspot.com/
> >
> > I'm going to go a pub, Stella's on Cambie
> >
> > Hiroshi
> > --
> > representative director of OpenStreetMap Foundaiton Japan sub-leader
> > of Sinsai.info - Ushahidi site for Japan disaster response Hiroshi
> > Miura - miur...@osmf.jp
> > facebook: miurahr, twitter: miurahr, osm: miurahr, and others.
> >
> >
> > ___
> > 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


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

Re: [Talk-ca] GeoTiff in JOSM

[Paul Norman]

> -Original Message-
> Subject: Re: [Talk-ca] GeoTiff in JOSM
> 
> On Fri, Sep 2, 2011 at 12:55 PM, penorman  wrote:
> > I'm at work and going on vacation so I can't give a detailed answer
> > for a few days, but this might help
> 
> No problem, any help is appreciated.
> 
> > Once the tiles are made you can serve the directories with apache or
> > another web server.
> 
> Ah, okay I didn't realize it was that simple.

I believe you can also have JOSM get files directly from your hard drive,
but I'm not sure the syntax  to do so on the Mac.
> 
> > xjjk from the OSM IRC channel has a parallized version of gdal2tiles
> > which can significantly help processing times if you have a multi-core
> CPU.
> 
> Would that be maptiler?

Maptiler is essentially a graphical front-end to gdal2tiles. Xjjk's version 
is the command line version modified. My iMac broke awhile back so I'm not 
sure how easy/hard GDAL is to set up with python bindings on OS X.

> I've got a dual quad-core Xeon Mac Pro with 14 gb of ram so a
> parallelized version would be a must. :)

You'll still be limited by your CPU :P

> I'll have to give it a shot and see how long it takes to process some
> portion of my GeoTiff.  The tiled GeoTiff is about 16 GB, where the
> original MrSid is 1.9GB.  Might be doable. :)

What I did for testing was work on a small section downloaded separately and
benchmarked with different image scaling methods. The three worth
considering are nearest, antialias, and lanczos. Nearest is fastest,
preserves sharp edges but has the worst quality. Antialias is decently fast,
decent quality. Lanczos is the best quality, preserves edges but is
extremely slow.


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

[Talk-ca] BC Highway tagging

[Paul Norman]

While reviewing the highways I travelled this long weekend (1, 5 to
Kamloops, 5 to Clearwater, 1;97 to Sushwap, 1 to Hope, 7 to Vancouver) I
came across some new tags on the relations. Taking Highway 7 as an example,
the changes were

-  The removal of name=Highway 7

-  Changing network=ca_bc_primary to network=CA:BC

 

On some other relations the tagging nhs=yes was added.
http://wiki.openstreetmap.org/w/index.php?title=Key:NHS

&action=history indicates that this tag was first documented on Sept 6 by
NE2.

 

The name=* tags for the tree of Trans-Canada relations also seems to of been
messed up.

 

I am going to be doing some cleanup work on the names, but I'm uncertain
what to do with the network tags. I'm unaware of any data consumers who
actually use this data and have no strong preferences myself. It does seem
wrong to change a consistent tagging standard with no prior discussion.

 

The nhs=* tag also seems useless. When I investigated the NHS during my
earlier work on consistent tagging of urban highways I found that NHS status
did not mean anything in practical terms and did not correspond to who was
responsible for road maintenance, who paid for the road, the condition of
the road, the size of the road, the importance of the road, the signing or
any other criteria I could think of.

 

Normally I would do a more detailed investigation but in this case it is
easier to fix the problem then fully investigate the exact details of the
changes.  The relations in question are large relations and I'm not always
able to determine when the changes were made through the web interface
without timeouts.

 

What are the thoughts of everyone on ca_bc_primary vs. CA:BC and the use of
nhs=yes?

 

Cc'ed NE2 since he may have been the one who made the changes.

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

[Talk-ca] New Surrey, BC Data/Imagery

[Paul Norman]

Apparently Surrey now has data for buildings in the city, likely based on
planning documents. I'm going to be trying to obtain a shapefile version to
see if it might be useful in some way. They also appear to of done a flight
this summer for imagery for everything north of the Serpentine river, which
I know will be useful.

 

I'll provide updates when I get more information, likely on Friday.

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

[Talk-ca] Goverments releasing data under PDDL

[Paul Norman]

Is anyone aware of a list of governments which are releasing datasets under
the PDDL? So far I am aware of

 

Surrey, BC (http://www.surrey.ca/city-services/658.aspx)

Township of Langley, BC (http://www.tol.ca/ServicesContact/OpenData.aspx)

City of Winnipeg, MB (http://api.winnipegtransit.com/)

 

I am particularly interested in any Canadian provincial governments
releasing data under this license.

 

I am planning on writing a letter to DataBC, a provincial government open
data initiative, suggesting they use PDDL as a widely accepted license that
accomplishes their intentions in licensing.

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

Re: [Talk-ca] GeoTiff in JOSM

[Paul Norman]

xjjk has put up his scripts at
http://caligula.rhombic.net/~xjjk/OpenStreetMap/scripts/

gdal2tiles-mp.py is the multi-threaded version
Rename-TMS-layout-to-Google-Layout.pycreates a script that renames
tiles. 

For your 6 hour run, what resampling did you use, how big was the source
GeoTIFF (with or without overviews) and what was the highest zoom range
done?

> From: Tyler Gunn [mailto:ty...@egunn.com]
> Subject: Re: [Talk-ca] GeoTiff in JOSM
> 
> > I believe you can also have JOSM get files directly from your hard
> > drive, but I'm not sure the syntax  to do so on the Mac.
> 
> I did a render with gdal2tiles and was able to get it working fine in
> Merkaator.  Something about the tile number origin being opposite in
> JOSM.
> 
> > Maptiler is essentially a graphical front-end to gdal2tiles. Xjjk's
> > version is the command line version modified. My iMac broke awhile
> > back so I'm not sure how easy/hard GDAL is to set up with python
> bindings on OS X.
> 
> Ah, okay.  I'll have to drop Xjik a line and see if I can get a copy
> of the modified command line file.   It seems there WAS a version of
> gdal2tiles tat was optimized for multi-core, but the author seems to be
> charging for it.
> 
> There is a pre-made gdal install package for OSX, so it was extremely
> easy to get up.  Click and install.
> 
> > You'll still be limited by your CPU :P
> 
> On a single core my 1.9GB image took around 6 hours.  So not too bad but
> faster would be nice.
> 
> > What I did for testing was work on a small section downloaded
> > separately and benchmarked with different image scaling methods. The
> > three worth considering are nearest, antialias, and lanczos. Nearest
> > is fastest, preserves sharp edges but has the worst quality. Antialias
> > is decently fast, decent quality. Lanczos is the best quality,
> > preserves edges but is extremely slow.
> 
> I'll have to try modifying the render settings and see how it goes.
> I'll probably want to get the parallelized version first though.
> 
> THanks!
> Tyler


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

Re: [Talk-ca] BC Highway tagging

[Paul Norman]

> From: Nathan Edgars II [mailto:nerou...@gmail.com]
> Subject: Re: BC Highway tagging
> 
> On 9/7/2011 11:37 PM, Paul Norman wrote:
> > While reviewing the highways I travelled this long weekend (1, 5 to
> > Kamloops, 5 to Clearwater, 1;97 to Sushwap, 1 to Hope, 7 to Vancouver)
> > I came across some new tags on the relations. Taking Highway 7 as an
> > example, the changes were
> >
> > -The removal of name=Highway 7
> 
> I see no reason to have this on the relation, and at least one reason to
> remove it (JOSM then sorts the relations by number rather than by name).

In the case of some highways (e.g. 1 through the lower mainland) they
clearly have a name, as is evident by the AM730 and 1130 reports as well as
common usage. In the case of Highway 7 I guess the name should have been
Lougheed Highway. For the 99 and 91 there is no commonly used name so it is
not clear that name=* is required, but I believe it is worth adding for
consistency. The relations will not be sorted in any meaningful order if
name is the primary sort key because of the routes that do have names.

> > -Changing network=ca_bc_primary to network=CA:BC
> 
> There were some network=CA:BC already.

There may have been some, but the vast majority were ca_bc_primary, and I
believe this comes from CanVec. It shouldn't be changed without some
discussion, because it will be continued to be used.

> > On some other relations the tagging nhs=yes was added.
> > http://wiki.openstreetmap.org/w/index.php?title=Key:NHS&action=history
> > <http://wiki.openstreetmap.org/w/index.php?title=Key:NHS&action=histor
> > y> indicates that this tag was first documented on Sept 6 by NE2.
> 
> I don't think I added this to any relations, only to ways. It's been in
> use in the US for about a year.

Ah, right, it was on ways. I was looking at users who had added this tag,
but were unable to identify any other than you. Could you point me at some
other names?

NHS=* seems questionable in the US. The FHWA states 

For motorists, the NHS has no separate identity that sets it aside from
other highways - no unique sign, no special color for road signs, no unique
design standard. It includes existing Interstate highways, future Interstate
highways that are simply lines on a map today, and thousands of miles of
two-lane roads without control of access, grade separation of interchanges,
median separation, or other needed safety features. And the NHS routes,
unlike the Interstate highways, have not been a magnet for economic
development.

As Senator Moynihan had predicted in 1991, the NHS remains a funding
category, similar to the Federal-aid primary category that had been
eliminated by ISTEA, and has resulted in the types of benefits associated
with the former category

(last paragraphs on http://www.fhwa.dot.gov/infrastructure/backbone.cfm)

After reading through the description of the US NHS, the Canadian NHS seems
even less relevant. The status on a federal government document which has no
impact in any way on the road to the users of the road and has minimal
impact on funding is not a verifiable feature, a ground truth and adds no
value to the users of the map.

I'm looking to do the cleanup this weekend as I plan to review approximately
1000 km of roads that I travelled on my holiday and it makes sense to do the
other work at the same time.


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

[Talk-ca] NHS=* in Canada and network types

[Paul Norman]

I'm hoping to do some highway work this weekend and would like to do any
changes to the highway tagging at this time. The two unresolved issues were

 

1.   NHS=yes on ways

 

The apparent reason for adding this was that it was used in the US and is
referenced on some Wiki pages. I've reread the Council of Ministers National
Highway System Review Task Force Report from 2005 [1] and still believe NHS
is of no relevance in Canada. I'd be skeptical about its relevance in the US
too, but I'm not a local there.

 

2.   Network tagging on relations

 

Relations have been a mix of ca_bc_primary and CA:BC. Rweait believes
ca_bc_primary came from ca_on_primary but I'm not sure where that was from.
It doesn't really matter which is used, but it should be consistent. Does
anyone know where ca_on_primary came from?

 

 

[1]: http://www.comt.ca/english/NHS-Report-English.pdf

 

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

Re: [Talk-ca] Alberta? Quebec? BC? Where are you?

[Paul Norman]

> -Original Message-
> From: Richard Weait [mailto:rich...@weait.com]
> It is wonderful to see the increasing numbers of OSM groups in Canada.
>  Fredericton, NB is the newest group to start, earlier this year, but
> who will be next?
> 
> Will it be Vancouver, or do Van-OSMers just pop across to Seattle to get
> their Mappy Hour needs filled?

We all are busy on our mountain bikes in the trails. :)

I'd be interested in a mappy hour in BC. I don't have the time to organize
one. I know there are a few of us in the New West/Coquitlam area so
something out this way might work. The other obvious location is downtown
Vancouver.


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

Re: [Talk-ca] Alberta? Quebec? BC? Where are you?

[Paul Norman]

> -Original Message-
> From: Alan McConchie [mailto:alan.mcconc...@gmail.com]
> 
> Would a compromise location like Metrotown work for you mappers in New
> West, Tri-Cities and South of Fraser?
> 
> I'm out at UBC and the westside of Vancouver, and I also feel too busy
> to organize a meetup, but I recognize we ought to start one anyway!
> 
> Alan

Metrotown would work for me, but I can't speak for alexz or mbiker, the two
mappers who I know are in the tri-cities. I am actually not aware of any
mappers south of the Fraser.

Metrotown itself looks decently mapped but it looks like a lot more could be
mapped in the surrounding area.

I commute between New West and either Richmond or UBC on weekdays, so pretty
much anywhere in the Lower Mainland is an option for me. 


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

[Talk-ca] Okanagan lake

[Paul Norman]

I noticed an issue with Okanagan lake in the BC Interior. June56 had
mistakenly messed it up and it was no longer rendering. After consultation
with them, I reverted changesets 9328821, 9338303 and 9338413 with changeset
9339109. I then restored the road and POI changes they had done in 9328821
with my changesets 9339176 and 9339178.

 

Everything should be good after a re-render of the area. I just don't want
anyone to panic if they see a missing lake.

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

Re: [Talk-ca] City of Fredericton Open Data website

[Paul Norman]

A quick reading of the terms of use at
http://www.fredericton.ca/en/citygovernment/TermsOfUse.asp seems to show
that they suffer from the same problems as the Vancouver terms of use and
are non-open. http://weait.com/content/unintended-restrictions has an
analysis of them.

 

This is not just a problem for OSM, but for anyone who does due diligence
and reads the license. 

 

The license also appears to be incompatible with the Vancouver license.

 

From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca] 
Sent: Monday, September 26, 2011 7:46 AM
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] City of Fredericton Open Data website

 

There has not been an announcement on this yet but the website is now
available:

http://www.fredericton.ca/en/citygovernment/DataMain.asp

 

Bernie.

 

--

Bernie Connors

New Maryland, NB

bernie.conn...@unb.ca

 

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

[Talk-ca] Proposed import: Surrey, BC waterways

[Paul Norman]

Back in April in
http://lists.openstreetmap.org/pipermail/talk-ca/2011-April/003929.html I
proposed importing data from Surrey, BC to replace the current OSM waterway
data for the city, which is derived from a NHD import. The license and
accuracy of the data is not an issue, the only questions that arose were
around the mapping of roadside drainage ditches.

 

The accuracy of the Surrey data is unquestionably better than the existing
OSM data. The NHD data includes streams that were paved over 25 years ago.

 

In summary, the import would consist of four categories.

 

1.   Streams. These typically meander, are in forested areas, are
natural, and have names. They are often nutrient-bearing for fish.

2.   Rural and agricultural ditches. These are long, straight, and
sometimes have culverts.

3.   Ditches in suburban areas. These are broken up by culverts and
eventually drain into the storm drain system.

4.   Culverts. These are in a separate file, and join the breaks
together.

 

At the time, no one was certain if adding ditches would cause the area to be
unwieldy to edit. Over the last couple of days, I have been mapping in
Queensborough, an area with very similar ditches.

 

http://www.openstreetmap.org/?lat=49.19043

&lon=-122.9372&zoom=17 is the area.

 

Ditches can be found on Lawrence, Wood south of Ewen, Boyne, Pembina north
of Ewen, Fenton and Johnston.

 

I have found that the ditches are not a problem when editing the area.
Adding the ditches takes some time to correctly split at culverts, but the
ditches to be import are already split.

 

The blue waterway=ditch lines are subtle on the gray landuse=residential
background and not overwhelming. I also looked at the osmarender and Open
Mapquest renderings, as well as an assortment of cloudmade renderings.

 

What I propose to do is process updated versions of the files and post them
for review. I have some old sample waterways at
http://maps.paulnorman.ca/surrey/samplewaterways.osm but additional work is
required, and I intend to use the latest shapefiles.

 

The waterways will be tagged with start_date, source, waterway, an ID in the
surrey:* namespace and the nutrient/fish status in the surrey:* namespace.

 

The nutrient/fish statuses are documented on
http://cosmos.surrey.ca/Geocortex/EssentialsExternal/Web/Metadata/metadata_e
xternal.html#drnFishClassifications

(broken HTML may be present)

 

 

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

[Talk-ca] Old CanVec versions

[Paul Norman]

Does anyone know where I can find old CanVec versions? I was looking into
http://www.openstreetmap.org/?lat=44.608497
 &lon=-63.629537&zoom=18&layers=M which I was pointed to on IRC and has a
footway and a track running over each other, but not sharing nodes and both
were from CanVec 6.0. CanVec 8.0 only has the footway.

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

[Talk-ca] Motorways tagging at ferry terminals/boarders

[Paul Norman]

There are two different and conflicting ways of tagging motorways at ferry
terminals. The first of these, as shown at the Horseshoe Bay terminal
http://osm.org/go/WJQnahqdV- is of having one way where there are many lanes
and tagging as highway=motorway. The second, shown at Swartz Bay
http://osm.org/go/WJEP9q90r- is drawing the lanes as highway=service and
terminating the motorway when it stops being one. 

 

The same issue applies at border crossings, except for the ones I've looked
at the choice is between highway=motorway and highway=primary.

 

I have reservations about tagging highway=motorway on a section of road that
has speed bumps, stop signs and traffic lights.

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

Re: [Talk-ca] Old CanVec versions

[Paul Norman]

I could use 092G and 092H. Is there any possibility of getting them hosted
on a generally accessible server? It's often useful to be able to check if a
problem was with the source data or an import.

 

From: Brent Fraser [mailto:bfra...@geoanalytic.com] 
Sent: Saturday, October 15, 2011 7:42 AM
To: Paul Norman
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Old CanVec versions

 

I've got  a copy of v6 on my network.  Did you want one sheet or all of it?




Best Regards,
Brent Fraser


On 10/15/2011 2:06 AM, Paul Norman wrote: 

Does anyone know where I can find old CanVec versions? I was looking into
http://www.openstreetmap.org/?lat=44.608497
<http://www.openstreetmap.org/?lat=44.608497&lon=-63.629537&zoom=18&layers=M
> &lon=-63.629537&zoom=18&layers=M which I was pointed to on IRC and has a
footway and a track running over each other, but not sharing nodes and both
were from CanVec 6.0. CanVec 8.0 only has the footway.






___
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

Re: [Talk-ca] Motorways tagging at ferry terminals/boarders

[Paul Norman]

> From: Richard Weait [mailto:rich...@weait.com]
> Subject: Re: [Talk-ca] Motorways tagging at ferry terminals/boarders
> 
> On Tue, Oct 18, 2011 at 12:35 PM, Matthew Buchanan
>  wrote:
> > I prefer the Swartz Bay scheme because it is more reflective of the
> > reality on the ground.
> 
> The "what"?  Could you provide a link please?  :-)

The two are ferry terminals mapped differently right now.

Basically, with the way Swartz Bay is mapped, the highway=motorway stops
when it is no longer physically a motorway. This results in a map that is
better for local navigation and on foot, but one that may have issues with
long distance navigation. I am not sure if it does or not.

The most obvious question to me is, what do we do to the route relations
that include the ferry terminals? For example, the Trans-Canada Highway
includes Horseshoe Bay and Departure Bay and it is not clear which road, if
any, should be in the relation if they were mapped like Swartz Bay. 

The 17 include Tsawwassen and Swartz Bay. What is currently done is the
route does not include the service roads leading to the ferry dock point,
but does include the ferry route. It also has FIXME=fix ferry

For any non-locals, this is a list of the major BC ferry terminals and the
relevant route relations:

Duke Point (Near Nanaimo, on Vancouver Island):
http://www.openstreetmap.org/?lat=49.16101&lon=-123.88407&zoom=15

Departure Bay (Near Nanaimo, on Vancouver Island):
http://www.openstreetmap.org/?lat=49.19126&lon=-123.95188&zoom=17

Swartz Bay (Near Sidney, on Vancouver Island):
http://www.openstreetmap.org/?lat=48.68638&lon=-123.40825&zoom=16

Tsawwassen (Near Ladner, on the mainland):
http://www.openstreetmap.org/?lat=49.0081&lon=-123.12499&zoom=16

Horseshoe Bay (Near West Vancouver, on the mainland):
http://www.openstreetmap.org/?lat=49.37437&lon=-123.27077&zoom=17

Highway 17 (Delta to Victoria):
http://www.openstreetmap.org/browse/relation/417826

Highway 1 (Trans-Canada): 

BC Super-relation: http://www.openstreetmap.org/browse/relation/417784

Mainland relation: http://www.openstreetmap.org/browse/relation/1308252

Island relation: http://www.openstreetmap.org/browse/relation/1308318




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

[Talk-ca] BC muncipial borders

[Paul Norman]

I've been looking at finishing up the BC municipal borders in the lower
mainland. Currently some are fairly approximate while others are missing
entirely. A few are in accurately. Is anyone aware of a good usable source?

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

[Talk-ca] High-visibility Vests

[Paul Norman]

In another thread, the subject of high-visibility vests came up and I was
wondering if there were any of these in North America. The wiki says the
existing ones are sold by the OpenCycleMap shop, but they are listed as
"temporarily unavailable". In any case, shipping clothing from Europe is
likely not the best option. Additionally, the vests aren't likely to meet
North American high-visibility standards.

 

In my day job I deal with high-vis vests too much, so I am familiar with
this subject area.

 

I believe a vest meeting CSA Z96, ANSI/ISEA 107 with "MOT" style trim would
meet the requirements for use on US federally funded rights of way (See
Federal Register/Vol 71, No 226/Friday November 24, 2006, p. 67792-67800),
BC MOT roadways (Technical Circular T-09/05), other BC roadways (OHSR 8.24 +
G8.24-1), Ontario, Saskatchewan, Manitoba, Alberta and I would expect the
rest of North America. The FWHA put the normal price of a vest at $25. The
maximum area of a non-retroreflective logo on a vest is 100 square cm.

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

Re: [Talk-ca] [Talk-us] High-visibility Vests

[Paul Norman]

For various reasons, the pattern used by vests in Canada (X on the back) is
not particularly common in the US or Europe.

 

From: Gregory [mailto:nomoregra...@googlemail.com] 
Sent: Thursday, October 27, 2011 5:04 AM
To: talk...@openstreetmap.org; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] [Talk-us] High-visibility Vests

 

I think it's better to order them in bulk, which the OpenCycleMap did and is
probably why they are unavailable.

Meeting a safety standard was a bit attractive so you can use them for other
uses that don't care about the logo. I think some European countries require
you to have a high-vis jacket in the car for when you break down. Some
mappers in the UK like to wear high-vis when cycling, so use their OSM one
even when not mapping.

 

When the SotM12 venue is announced it might be could for all countries to
see what the interest is and then let Andy Allan (of OpenCycleMap) know or
someone do an order of several. Having them available at something like SotM
is easier/cheaper than individual deliveries.

 

On 24 October 2011 03:39, Martijn van Exel  wrote:

I have about a dozen of them and am happy to lend them for mapping
party purposes.
They look like this: http://schaaltreinen.nl/openstreetmap-hi-viz-vest
If it looks a little wrinkly, that's because I brought them from Europe ;)

Martijn


On Sun, Oct 23, 2011 at 6:12 PM, Paul Norman  wrote:

> In another thread, the subject of high-visibility vests came up and I was
> wondering if there were any of these in North America. The wiki says the
> existing ones are sold by the OpenCycleMap shop, but they are listed as
> "temporarily unavailable". In any case, shipping clothing from Europe is
> likely not the best option. Additionally, the vests aren't likely to meet
> North American high-visibility standards.
>
>
>
> In my day job I deal with high-vis vests too much, so I am familiar with
> this subject area.
>
>
>
> I believe a vest meeting CSA Z96, ANSI/ISEA 107 with "MOT" style trim
would
> meet the requirements for use on US federally funded rights of way (See
> Federal Register/Vol 71, No 226/Friday November 24, 2006, p. 67792-67800),
> BC MOT roadways (Technical Circular T-09/05), other BC roadways (OHSR 8.24
+
> G8.24-1), Ontario, Saskatchewan, Manitoba, Alberta and I would expect the
> rest of North America. The FWHA put the normal price of a vest at $25. The
> maximum area of a non-retroreflective logo on a vest is 100 square cm.
>

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



--
martijn van exel
geospatial omnivore
1109 1st ave #2
salt lake city, ut 84103
801-550-5815
http://oegeo.wordpress.com

___
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

[Talk-ca] Proposal: Removing imported aboriginal land

[Paul Norman]

In 2010 acrosscanadatrails imported Aboriginal reserves. An example is
http://www.openstreetmap.org/browse/relation/1016901

 

These are viewable all the way out to z4.

 

I propose removing these for a few reasons.

 

1.   From what I've seen, no one has edited these to improve them.

2.   Acrosscanadatrails has not agreed to the CTs. He has indicated his
contributions are public domain, so the data could be downloaded and
reimported, but I do not believe that should be done.

3.   The tagging is questionable, with two FIXMEs. They are tagged with
admin_level=4, the same as provinces, which misrepresents their importance.

4.   The tagging for aboriginal lands is not settled. See
http://wiki.openstreetmap.org/wiki/Talk:Key:boundary#First_Nations for some
discussion. Although this shouldn't stop people from mapping them, I believe
it should stop them from being imported.

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

[Talk-ca] Calgary Area Trail Mapping Project

[Paul Norman]

I was looking at the new truck rendering layer at
http://www.itoworld.com/product/data/ito_map/main?view=160 and ran across an
import called the Calgary Area Trail Mapping Project. This is, as far as I
can tell, the only significant use of hgv=* between Vancouver and Toronto.
Does anyone know anything about it? The hgv=* (and other access) tags on
http://www.openstreetmap.org/browse/way/26574987 seem somewhat out of place.

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

Re: [Talk-ca] Calgary Area Trail Mapping Project

[Paul Norman]

> From: si...@mungewell.org [mailto:si...@mungewell.org]
> Subject: Re: [Talk-ca] Calgary Area Trail Mapping Project
> 
> 
> > I ran across some trails from the project when out on a week long
> > horseback riding camp...
> >
> > http://www.openstreetmap.org/?lat=52.0671916007996&lon=-115.9683108329
> > 77&zoom=14
> >
> > The roads there are tagged as hgv=no, and are indeed not suitable for
> > most passenger cars.
> >
> > The hgv classification possibly being mistaken for High
> > Ground-clearance Vehicle rather than Heavy Goods Vehicle.
> >
> 
> The project is mostly aimed at building a Garmin format map, and I think
> that are using some of the Garmin tags to convey other information -
> such as 'hgv=no' to indicate that the route is not suitable for 'normal'
> driving.
> 
> I did do the initial import, but am busy with other project and we're
> also a little out of date compared to their latest version.
> 
> Simon.
> 

Are you okay with the tagging being fixed where it hasn't been touched by
subsequent users? Right now it's rendering on the ITO truck layer as being
suitable for a truck (since that's how it's tagged)

If there's any documentation about what the values mean in the datasource it
would be helpful.

The import account hasn't agreed to the CTs. Is this an oversight, or are
there legal reasons preventing it from agreeing?


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

[Talk-ca] Surrey Open Data Hackathon

[Paul Norman]

Surrey, BC is holding an Open Data Hackathon on Sunday November 20th. More
details are at http://www.surrey.ca/city-services/10036.aspx

 

I will be attending and looking at writing some new conversion scripts.

 

Does anyone have suggestions for any printed OSM materials to bring?

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

[Talk-ca] network=* tags

[Paul Norman]

I'm writing this late at night so hopefully everything make sense.

 

Currently there are two competing schemes for the network=* tag. The first
of these is ca_bc_primary and the second is CA:BC. (Using the example of a
numbered route in BC)

 

I propose moving to one standard. I do not know which is better. I have no
strong opinions one way or the other as BC only has primary highways (or
more precisely doesn't classify them)

 

Points in favour of ca_bc_primary:

Less escaping of special characters

In use longer

 

Points in favour of CA:BC

Closer to what the US and other countries use

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

Re: [Talk-ca] Fwd: [OSM-talk] Argh, Canvec imports

[Paul Norman]

> From: James Ewen [mailto:ve6...@gmail.com]
> Subject: Re: [Talk-ca] Fwd: [OSM-talk] Argh, Canvec imports
> 
> On Thu, Nov 17, 2011 at 5:18 AM, Richard Weait 
> wrote:
> 
> > I do bimonthly runs of the worldwide coastlines
> > (http://metro.teczno.com/#coastline), and Canada seems to be a
> > recurring source of problems. What the heck is going on up there? I
> > consistently see new imports of what seems to be Canvec data screwing
> > up coastlines and making for some deeply broken renders:
> 
> From what I hear, it's people changing the tagging in an effort to tag
> for the renderer. They are changing tags trying to get the OSM map to
> look "right" to them. In doing so, it breaks things. With the bi-monthly
> rendering runs, it is possible for people to screw up a lot of coastline
> before finding out that they are breaking it instead.

I know that two people on IRC spent a few hours clearing up Hudson Bay and
the problems weren't tagging for the renderer, it was mis-tagging and
coastlines as multipolygons, of all things.

My view is that anyone who is importing in a coastal area needs to have the
skillset to make sure that the coastlines are correct, and if they cannot be
confident they are not messing the coastline up, they should not import.

Personally, I've found the best way to deal with CanVec coastlines is to
strip all the tags off of them, merge them to the right layer, and then put
the tags on and make sure they're in the right direction.


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

[Talk-ca] Surrey Roads Data

[Paul Norman]

I have updated  my Surrey roads data, available at
http://maps.paulnorman.ca/surrey/SurreyRoads2011Nov.zip

New in this release:
- Updated source tagging
- gritting (snowplough) information added

I find the data most useful for importing to replace unnamed roads and clear
naming mistakes.

Known deficiencies
- Some highway=service are not connected. This is a source data issue
- Some roads closed for long term construction around the Port Mann are
still considered open
- An occasional way is over-noded
- There may be some truck route information in the ROUTE0 attribute that is
not being converted to hgv=* tags
- "No" is not expanded to "Number" in road names

I intend to go over the streets with a start_date more recent than 2009 and
add them if necessary.


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

Re: [Talk-ca] new goodies on OSM --> Canvec artifacts

[Paul Norman]

> From: Frank Steggink [mailto:stegg...@steggink.org]
> Subject: Re: [Talk-ca] new goodies on OSM --> Canvec artifacts
> 
> Due to the use of Natural Earth (?) as a base layer, certain artifacts
> from the Canvec import become more visible, especially at the lower (<=
> 7) zoomlevels. See for example the coastline issues in Atlantic Canada:
> http://www.openstreetmap.org/?lat=45.31&lon=-63.13&zoom=7&layers=T .
> Perhaps unintentional, but this rendering can help us a lot cleaning up
> after certain imports. So, I hope this rendering won't be adjusted
> soon... :)
>

I sent a message to the user who appears to of done most of the uploads
there, asking if he wants to fix it, or leave it to someone else. It looks
like they were done over existing data (which may of just been the
coastlines) and not correctly tied into the coast.

As a plea to anyone considering CanVec imports near an ocean, reconsider.
These are *very* hard to get right and problems may not be obvious because
the coastlines do not re-render right away. Doing them right is also very
time-consuming because the CanVec tagging on the coast is wrong.


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

[Talk-ca] Surrey Imagery

[Paul Norman]

Thanks to iandees, the imagery from Surrey BC is now mirrored with an OSM US
server. It can be accessed with an imagery URL of
tms[10,20]:http://{switch:a,b,c}.tile.osm.osuosl.org/tiles/bc_surrey_2011/{z
oom}/{x}/{y}.png in JOSM, or
http://a.tile.osm.osuosl.org/tiles/bc_surrey_2011/$z/$x/$y.png in Potlatch2.


This URL should bring up PL2 in Queens Park, New Westminster with the
imagery loaded.
http://www.openstreetmap.org/edit?editor=potlatch2&lat=49.215&lon=-122.903&z
oom=17&tileurl=http://a.tile.osm.osuosl.org/tiles/bc_surrey_2011/$z/$x/$y.pn
g

The tiles are cached on the osuosl server but uncached tiles are accessed
from my home server. This is blazingly fast for me, but not so fast for
everyone else. Expect a bit of a delay at high zooms as it fetches the data.
I have pre-fetched the lower zooms.

The data is licensed under the PDDL and suitable for tracing from. Running
off of my home server, this service is only for OSM and not for other
projects. 

The imagery was flown in April-May 2011 and captured digitally at a 10cm
resolution. There are moderate leafs on the trees. The imagery is more
accurate than consumer grade GPS. The extents of the imagery are the north
end of the Port Mann, 800m south of the US border, 204 Street in Langley,
and a line running from approximately 19th Ave and 2nd St in Burnaby through
the east part of Queensborough and Annacis Island and down near 104th Street
in Delta. This includes all of Surrey, most of New Westminster, a large part
of Pitt Meadows, Barnston Island, most of North Delta, part of Langley City,
all of White Rock and part of Burnaby and Coquitlam.

Technical details: The imagery was converted from mrsid files to GeoTIFFs
and then a parallized version of gdal2tiles converted it into TMS tiles with
lanczos resampling.

If the load becomes excessive I will have to throttle my server but I do not
anticipate the need to do so. Many thanks to Ian for mirroring this.

My standard offer of the imagery to anyone who supplies the dual-layer DVDs
necessary to transfer it applies.


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

Re: [Talk-ca] new goodies on OSM --> Canvec artifacts

[Paul Norman]

> From: Paul Norman [mailto:penor...@mac.com]
> Sent: Sunday, November 27, 2011 12:43 AM
> To: 'Frank Steggink'; talk-ca@openstreetmap.org
> Cc: gravityst...@gmail.com; impo...@openstreetmap.org
> Subject: Re: [Talk-ca] new goodies on OSM --> Canvec artifacts
> 
> > From: Frank Steggink [mailto:stegg...@steggink.org]
> > Subject: Re: [Talk-ca] new goodies on OSM --> Canvec artifacts
> >
> > Due to the use of Natural Earth (?) as a base layer, certain artifacts
> > from the Canvec import become more visible, especially at the lower
> > (<=
> > 7) zoomlevels. See for example the coastline issues in Atlantic
> Canada:
> > http://www.openstreetmap.org/?lat=45.31&lon=-63.13&zoom=7&layers=T .
> > Perhaps unintentional, but this rendering can help us a lot cleaning
> > up after certain imports. So, I hope this rendering won't be adjusted
> > soon... :)
> >
> 
> I sent a message to the user who appears to of done most of the uploads
> there, asking if he wants to fix it, or leave it to someone else. It
> looks like they were done over existing data (which may of just been the
> coastlines) and not correctly tied into the coast.

After getting no response, I am currently working on going through this
user's changesets, which appear to be mainly CanVec imports not conducted in
accordance with the guidelines (not from a separate account) and will be
reverting those done over existing data or that are otherwise badly broken.


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

Re: [Talk-ca] Canvec 7 and lanes=-1 / surface=unpaved

[Paul Norman]

lanes=* and surface=* are present in BC (e.g. 092G02)

 

surface=unpaved is wrong for the most part - they're generally paved back
lanes.

 

From: Begin Daniel [mailto:jfd...@hotmail.com] 
Sent: Wednesday, January 18, 2012 7:33 PM
To: rich...@weait.com; harald.kli...@mail.mcgill.ca
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec 7 and lanes=-1 / surface=unpaved

 

Hi Richard
AFAIK the lane=* has never been used in Canvec. I know that the
surface=unpaved has been used in the Canvec product as unknown value but
only in Quebec. Never in other provinces.
Cheers
Daniel

> Date: Wed, 18 Jan 2012 16:50:37 -0500
> From: rich...@weait.com
> To: harald.kli...@mail.mcgill.ca
> CC: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Canvec 7 and lanes=-1 / surface=unpaved
> 
> On Wed, Jan 18, 2012 at 4:16 PM, Harald Kliems
>  wrote:
> > Hi everyone,
> >
> > can someone please tell me what's up with the lanes=-1 and
surface=unpaved tags on most roads imported from Canvec 7? I didn't find any
information on the Canvec wiki page. Do those tags stand for "number of
lanes/surface unknown"? Wouldn't it then be better to remove them with a bot
(at least the lane tags; with the surface ones it'll be tricky to
distinguish between actually unpaved roads and import errors). Sorry if this
is an old, already resolved issue -- I just couldn't find any information
about it and come across it all the time.
> 
> I think v8 is current and I haven't noticed that issue.
> 
> ___
> 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

Re: [Talk-ca] Canadian-specific boundary tweaks for MkGMap

[Paul Norman]

The administrative boundaries in the lower mainland are not complete. I've
been looking for a source for the rest of them, but haven't found one.

 

From: SAMUEL LONGIARU [mailto:longi...@shaw.ca] 
Sent: Sunday, January 22, 2012 1:42 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Canadian-specific boundary tweaks for MkGMap

 

Good Afternoon Everyone, 

I've been lurking on the MkGMap developers list for several months now and
see that recently, they have solved some major issues regarding finding
streets when OSM is imported for use on Garmin GPS's... without the use of
MapSource!  They are now moving on to the problem of locating by house
number.  That's a great accomplishment and the developers deserve a lot of
credit.!!!  Very well done.

Don't know if anyone else has been playing with this, but in short, there
may need to be some Canadian-specific tweaks placed into the default style
files that are packaged with MkGMap.  Through adjustments to the MkGMap
command line options, I've been able get the location function to work
fairly well in my Nuvi 255, but have run into the issue where I can find
Granville Street in "Vancouver" but Hastings Street can only be found under
"Gastown" and Dundas Street under "Capitol Hill".  These should all be found
in Vancouver.

My first guess is that the administrative boundary levels need to be
tweaked, not in OSM but in the MkGMap style files where some recasting can
take place.  They already have country-specific tweaks for about 20 European
countries but nothing for Canada yet.

I was just wondering if anyone has a customized MkGMap style file that works
logically with the way administrative boundaries have been set up in Canada?
If so, and we can show that it works well with r2179, their most  recent
stable version, we could probably pass it on to them for inclusion in the
packaged style files so that the location function will work by default on
Canadian extracts.  Assuming you're willing to share of course :)

Thanks...

Sam Longiaru,
Kamloops, BC

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

Re: [Talk-ca] Canadian-specific boundary tweaks for MkGMap

[Paul Norman]

Surrey and Township of Langley borders were imported by me, which also got
all of the City of Langley and White Rock borders in at the same time. I've
mapped the New West border from street signs and local knowledge. Another
user got the north shore and some of the tri-cities area. Burnaby,
Vancouver, Richmond and Delta are all incomplete I believe.

 

From: Samuel Longiaru [mailto:longi...@shaw.ca] 
Sent: Sunday, January 22, 2012 3:56 PM
To: Paul Norman
Cc: talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Canadian-specific boundary tweaks for MkGMap

 


Ah... well that could be the issue.  I was not aware of that.  I thought
those were established a while ago through a GeoBase import.  Thanks.

Sam

-Original Message-
From: Paul Norman mailto:paul%20norman%20%3cpenor...@mac.com%3e> >
To: 'SAMUEL LONGIARU'  >,
talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Canadian-specific boundary tweaks for MkGMap
Date: Sun, 22 Jan 2012 15:25:57 -0800

The administrative boundaries in the lower mainland are not complete. I've
been looking for a source for the rest of them, but haven't found one.

 




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

Re: [Talk-ca] Cleanup

[Paul Norman]

> From: Richard Weait [mailto:rich...@weait.com]
> Sent: Thursday, January 26, 2012 10:24 AM
> To: Talk-CA OpenStreetMap
> Subject: [Talk-ca] Cleanup
> 
> Most of the Canadian data that needs cleaning is very low impact.
> 
> Two of the high-volume decline accounts are primarily imports that have
> not been subsequently edited.  That means the effected data can easily
> be re-imported for a net-zero change.
> 
> I recommend that we remove that data now, without delay.  That will
> simplify current cleanup activities by:
> - removing trivial doomed data
> - making interesting data cleaning opportunities easier to see
> 
> I'd like to request that the data working group purge that data for us.
> What do you think about requesting the removal of objects that
> are:
> 
> - created by the known-bad accounts
> - version 1 (that is, they have not been modified by another mapper)
> - not ways tagged natural=coastline
> 
> That will reduce the cleanup in Canada by about an order of magnitude
> with zero negative effect.
> 
> Thoughts?  Request this of DWG, or no?
> 

Not yet. I'm working on cleaning up some bad imports from accounts that have
not agreed to the CTs and would like to finish these first.

Also, what do you mean by known-bad accounts? 


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

Re: [Talk-ca] Clean up - natural coastline

[Paul Norman]

> From: James A. Treacy [mailto:tre...@debian.org]
> Subject: Re: [Talk-ca] Clean up - natural coastline
> 
> On Sat, Jan 28, 2012 at 10:33:09AM -0500, Andrew Allison wrote:
> > Hello:
> > I'm in the process of recreating non-ct data.
> 
> What areas need to be replaced?
>

I know that some PGS coastline imports are not CT-clean. Importing a
coastline from CanVec to replace the PGS data is on my list to-do, but I
don't see it happening before CanVec 9.0 since the current coastline model
is broken on the west coast and it takes about an hour a tile when there's
no other data to replace.


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

Re: [Talk-ca] Clean up - natural coastline

[Paul Norman]

> From: David Groom [mailto:revi...@pacific-rim.net]
> Subject: Re: [Talk-ca] Clean up - natural coastline
> - Original Message -
> From: "Andrew Allison" 
> Subject: [Talk-ca] Clean up - natural coastline
> 
> 
> > Hello:
> > I'm in the process of recreating non-ct data.
> >
> > Any gotchas that I should look out for in replacing coastline data.
> 
> 2 main ones -
> 
> A) direction ( see below),
> 
> B)  coastline ways when taken together should always form an unbroken
> line
> around a land mass.
> 
> minor "gotchas"
> 
> C)  the coastline import from PGS caused a number of small "artefacts"
> to be
> created, (many 3 node triangles of coastline appearing).  These are not
> true
> coastline, so need to be dealt with.
> 
> D) In places the coastline import was run over an area which was well
> inland
> of the true coast. The import found water bodes (lakes and rivers) in
> these
> areas, and created them as coastline.  When recreating these ways it
> would
> make sense to tag these correctly.  Note very large lakes may still have
> to
> be tagged as coastline however.
> 
> Note, that a lot off C & D's I have tried to clear up over the last few
> months, but I'm still working through them.
> 
> >
> > Pros and Cons of shorter ways.
> 
> Some of the PGS imports have created very short ways (I've come across
> whole
> km of coastline made up of many 2 or 3 node ways)
> 
> In general when I've been tidying coastlines I've tried to join any
> sections
> of coastline less than 40 nodes.
> 
> Similarly I've come across some very long ways. In general (and its a
> personal view which I don't always adhere to myself) I don't like ways
> which
> are longer than 1,000 nodes.
> 
> >
> > Does direction matter?
> 
> YES YES YES.  Coastline ways MUST be drawn with the water to the right.
> 
> >
> > How often is coastline data updated?
> 
> Do you mean, "how often is the coastline file used to render the coast
> on
> the Mapnik layer" updated.  The answer is periodically, but generally
> every
> 4 - 6 weeks
> 
> David
> 
> 
> >
> > Hope I keep every bodies feet dry and I don't damage something and
> find
> > out next month that I messed up big time.
> >
> > Or don't bother "we" are working on that :-)
> >
> >
> > Andrew
> > aka Purple Mustang.
> >

I've worked out how to get the GeoBase NHN coastline into .osm format and
plan to work on the west coast. The PGS is low resolution and there's no
other data for most of the area.

I don't want to import CanVec, partially because of the extensive coastline
cleanup work required to import it properly, partially because I don't see
that it adds value importing all of CanVec in an area where it won't be
maintained.


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

Re: [Talk-ca] Aboriginal Lands

[Paul Norman]

If the aboriginal lands are the same as were previously imported in BC I
don't think they're really suitable for use. A single reserve is split up
into much smaller areas at each of the roads. While I'm sure this is legally
correct, it's not much use for mapping.

I think boundary=aboriginal_land is the best tagging for them. It might be
worth talking with talk-us@ as well for the exact value - reserves in the US
are similar to those in Canada.

> -Original Message-
> From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]
> Sent: Thursday, February 09, 2012 1:54 PM
> To: Tyler Gunn; talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Aboriginal Lands
> 
> Bonjour Tyler,
> 
> Aboriginal Lands are already available in shape and gml format on
> GeoBase website. It provides a dataset for the entire country.
> 
> The Canvec product is produced on 50K map sheet coverage. The Aboriginal
> Lands, if provided through Canvec.osm product, will complied to the 50K
> map sheet coverage.
> 
> Best regards,
> Daniel
> 
> -Original Message-
> From: Tyler Gunn [mailto:ty...@egunn.com]
> Sent: February 9, 2012 16:38
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Aboriginal Lands
> 
> > It is possible to include Aboriginal Lands in the next release of
> > Canvec.osm. However, I'm trying to find a consensus in the community
> > concerning the tags/values to use?
> > I've found some links to...
> > - boundary=administrative; admin_level =aboriginal_land
> > - boundary=administrative; admin_level =2 to 4
> > - boundary=protected_area; protect_class=24
> 
> I'm curious how this information would be represented given the
> distribution of CanVec data in a tiled format?   Given that
> administrative boundaries tend to span larger areas, I don't know if it
> would make sense to split these at tile boundaries.  Were you thinking
> to provide these boundaries in a separate file of sorts?
> 
> How these boundaries are represented should perhaps be driven from where
> they fit into the overall picture in terms of how Canada is split up?
> 
> When I think of things like the country, provinces, territories,
> cities/towns/etc, these all fit nicely into the boundary=administrative
> and admin_level hierarchy.
> We have separate boundary types for provincial parks, national parks,
> etc, and I'd probably interpret the aboriginal lands the same way.
> 
> So I think its entirely reasonable to represent these as:
> boundary=aboriginal_land
> 
> Tyler
> 
> ___
> 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


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

Re: [Talk-ca] Administrative Boundary

[Paul Norman]

Can you give an example of a municipal regional or upper municipality?
Looking at the global usage, admin_level=5 is seldom used. I would think
that Municipal Regional would be 6 and upper municipality would be 7, but I
can’t really say without examples.

 

I would also suggest that these features in the .osm file not be closed –
just have the boundary, don’t handle it like lakes where you have multiple
areas you need to join where they cross tile bounds.

 

From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] 
Sent: Thursday, February 09, 2012 1:39 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Administrative Boundary

 

Bonjour again! 

Available administrative boundary will be included in the next release of
Canvec.osm.  From the wiki, here is the tagging values I'm going to use…

Municipal Regional:  boundary=administrative; admin_level=5 
Upper municipality:  boundary=administrative; admin_level=6 
Municipality:boundary=administrative; admin_level=8 

 
http://wiki.openstreetmap.org/wiki/Admin_level (Canada) 

 

Municipality admin_level=8 corresponds to gdf order in ISO standard. 
  
Municipal Regional Area and Upper Municipality (admin_level=5 and 6) are
different from what the ISO standard says (gdf order=6 and 7). Is someone
can confirm that admin_level=5 and 6 is really what is expected?

Thanks again 

Daniel Bégin 
Centre d'information topographique de Sherbrooke 
Topographic Information Center of  Sherbrooke
Ressources Naturelles Canada / Natural Ressources Canada
2144, rue King Ouest, bureau 010
Sherbrooke (Québec) J1J 2E8
(819) 564-5600 ext.242, dbe...@nrcan.gc.ca 





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

Re: [Talk-ca] Clean up - natural coastline

[Paul Norman]

I have completed some tests in Northern BC replacing PGS coastline with GeoBase 
coastline. This is equivalent to extracting the coastline from CanVec. Doing 
this is largely waiting for the API  to respond, as well as verification and 
dealing with edges and rivers

Sent from my iPad

On Jan 28, 2012, at 7:55 PM, Paul Norman  wrote:

>> From: James A. Treacy [mailto:tre...@debian.org]
>> Subject: Re: [Talk-ca] Clean up - natural coastline
>> 
>> On Sat, Jan 28, 2012 at 10:33:09AM -0500, Andrew Allison wrote:
>>> Hello:
>>>I'm in the process of recreating non-ct data.
>> 
>> What areas need to be replaced?
>> 
> 
> I know that some PGS coastline imports are not CT-clean. Importing a
> coastline from CanVec to replace the PGS data is on my list to-do, but I
> don't see it happening before CanVec 9.0 since the current coastline model
> is broken on the west coast and it takes about an hour a tile when there's
> no other data to replace.
> 
> 
> ___
> 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

Re: [Talk-ca] Canadian Municipal Open Data Licenses

[Paul Norman]

I make extensive use of the data from Surrey and Langley and consider them
to be models of the best practice for open data licensing, with all their
data licensed under PDDL.

> -Original Message-
> From: Richard Weait [mailto:rich...@weait.com]
> Sent: Sunday, February 12, 2012 1:55 PM
> To: Talk-CA OpenStreetMap
> Subject: [Talk-ca] Canadian Municipal Open Data Licenses
> 
> Dear all,
> 
> I've sent a note to a couple of Canadian municipalities about getting
> permission to use the open data they publish in OpenStreetMap.  I'll let
> you know the responses.  If I haven't said anything about this in a few
> weeks, please remind me.
> 
> The history of ad-hoc licenses and terms of use, the relatively new
> state of international data law and the international scope of OSM make
> it hard to "just accept" their ad-hoc licenses. Or to judge them as
> compatible.  I hope that those publishers will say the equivalent of,
> "yes, we want you to include our municipal data in OSM", and then we can
> rely upon that.
> 
> Presuming that permission is granted, the usual import guidelines will
> still apply.  :-)  But having more sources is better than having fewer
> sources. (Unless you have to choose among multiple disagreeing
> sources.)
> 
> I've added their attribution messages to the wiki[1] so that they can
> see how we'll credit them.
> 
> Best regards,
> Richard
> 
> [1]
> http://wiki.openstreetmap.org/wiki/Contributors#Canadian_Municipalities
> 
> ___
> 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

[Talk-ca] British Columbia Coastlines

[Paul Norman]

For the last couple of weeks I have been replacing the portions of the BC
coastline which were PGS or CT-dirty imports with the latest CanVec/GeoBase
data. I elected to use GeoBase since it's coastlines require less manual
processing to get into workable form. This process is now finished, with the
exception of the basins that are in the US and have data in GeoBase and the
08OA000 and 08OB000 basins (Haida Gwaii) which are in progress.

Before replacing any coast, I compared it with the GeoBase data for
accuracy. For most of BC's 25000 km of coastline the data was PGS data and
easily replaced. The only places where there was substantial coastline
retained were in Greater Vancouver, Victoria, Nanaimo and Sidney. The
quality of the OSM coastline data exceeds that of GeoBase/CanVec in these
areas.

All the data was run through JOSM's simplify function with a max-error of
1.5m. On later runs, short ways were combined into larger ones after
simplification. The search expression "(parent child selected | parent
selected) nodes:-1000" was used in doing this.

In the process I identified many unmapped rivers where I needed to join two
sections of coastline together. Where bing imagery showed a river, I added a
brief tracing. Most of the bing imagery was low-resolution Landsat or
higher-resolution imagery from the BC government, the same as is found on
their openmaps WMS server.

In the process, I ran JOSM's validator tool over most of the coastline and
fixed other unrelated errors.

Statistics:
The .osm files were 232 MB on disk before simplification
The total number of objects uploaded is approximately 1.5 million
Surprisingly, no errors were found by coastcheck in the coastline,
indicating my procedures worked
There are 47 NHN basins with coastline, varying in complexity and size from
5k nodes before simplification to 150k nodes before simplification


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

Re: [Talk-ca] Aboriginal Lands

[Paul Norman]

Does this mean that they would form closed areas split like large lakes are?
If so, this makes them unsuitable for importing into OSM without significant
work.

Can we see an example area so that we know what you are proposing?

> -Original Message-
> From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]
> Sent: Thursday, February 09, 2012 1:54 PM
> To: Tyler Gunn; talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Aboriginal Lands
> 
> Bonjour Tyler,
> 
> Aboriginal Lands are already available in shape and gml format on
> GeoBase website. It provides a dataset for the entire country.
> 
> The Canvec product is produced on 50K map sheet coverage. The Aboriginal
> Lands, if provided through Canvec.osm product, will complied to the 50K
> map sheet coverage.
> 
> Best regards,
> Daniel
> 
> -Original Message-
> From: Tyler Gunn [mailto:ty...@egunn.com]
> Sent: February 9, 2012 16:38
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Aboriginal Lands
> 
> > It is possible to include Aboriginal Lands in the next release of
> > Canvec.osm. However, I'm trying to find a consensus in the community
> > concerning the tags/values to use?
> > I've found some links to...
> > - boundary=administrative; admin_level =aboriginal_land
> > - boundary=administrative; admin_level =2 to 4
> > - boundary=protected_area; protect_class=24
> 
> I'm curious how this information would be represented given the
> distribution of CanVec data in a tiled format?   Given that
> administrative boundaries tend to span larger areas, I don't know if it
> would make sense to split these at tile boundaries.  Were you thinking
> to provide these boundaries in a separate file of sorts?
> 
> How these boundaries are represented should perhaps be driven from where
> they fit into the overall picture in terms of how Canada is split up?
> 
> When I think of things like the country, provinces, territories,
> cities/towns/etc, these all fit nicely into the boundary=administrative
> and admin_level hierarchy.
> We have separate boundary types for provincial parks, national parks,
> etc, and I'd probably interpret the aboriginal lands the same way.
> 
> So I think its entirely reasonable to represent these as:
> boundary=aboriginal_land
> 
> Tyler
> 
> ___
> 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


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

Re: [Talk-ca] Aboriginal Lands

[Paul Norman]

Then I don't think they should be included in canvec.osm

> -Original Message-
> From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]
> Sent: Monday, February 13, 2012 6:04 AM
> To: Paul Norman
> Cc: talk-ca@openstreetmap.org
> Subject: RE: [Talk-ca] Aboriginal Lands
> 
> Bonjour again Paul,
> 
> An example is not yet available but yes, it will form closed area split
> like large lake.  That is a limitation of the Canvec.osm product for the
> moment :-(
> 
> Daniel
> 
> -Original Message-
> From: Paul Norman [mailto:penor...@mac.com]
> Sent: February 13, 2012 05:35
> To: Bégin, Daniel; 'Tyler Gunn'; talk-ca@openstreetmap.org
> Subject: RE: [Talk-ca] Aboriginal Lands
> 
> Does this mean that they would form closed areas split like large lakes
> are?
> If so, this makes them unsuitable for importing into OSM without
> significant work.
> 
> Can we see an example area so that we know what you are proposing?
> 
> > -Original Message-
> > From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]
> > Sent: Thursday, February 09, 2012 1:54 PM
> > To: Tyler Gunn; talk-ca@openstreetmap.org
> > Subject: Re: [Talk-ca] Aboriginal Lands
> >
> > Bonjour Tyler,
> >
> > Aboriginal Lands are already available in shape and gml format on
> > GeoBase website. It provides a dataset for the entire country.
> >
> > The Canvec product is produced on 50K map sheet coverage. The
> > Aboriginal Lands, if provided through Canvec.osm product, will
> > complied to the 50K map sheet coverage.
> >
> > Best regards,
> > Daniel
> >
> > -Original Message-
> > From: Tyler Gunn [mailto:ty...@egunn.com]
> > Sent: February 9, 2012 16:38
> > To: talk-ca@openstreetmap.org
> > Subject: Re: [Talk-ca] Aboriginal Lands
> >
> > > It is possible to include Aboriginal Lands in the next release of
> > > Canvec.osm. However, I'm trying to find a consensus in the community
> > > concerning the tags/values to use?
> > > I've found some links to...
> > > - boundary=administrative; admin_level =aboriginal_land
> > > - boundary=administrative; admin_level =2 to 4
> > > - boundary=protected_area; protect_class=24
> >
> > I'm curious how this information would be represented given the
> > distribution of CanVec data in a tiled format?   Given that
> > administrative boundaries tend to span larger areas, I don't know if
> > it would make sense to split these at tile boundaries.  Were you
> > thinking to provide these boundaries in a separate file of sorts?
> >
> > How these boundaries are represented should perhaps be driven from
> > where they fit into the overall picture in terms of how Canada is
> split up?
> >
> > When I think of things like the country, provinces, territories,
> > cities/towns/etc, these all fit nicely into the
> > boundary=administrative and admin_level hierarchy.
> > We have separate boundary types for provincial parks, national parks,
> > etc, and I'd probably interpret the aboriginal lands the same way.
> >
> > So I think its entirely reasonable to represent these as:
> > boundary=aboriginal_land
> >
> > Tyler
> >
> > ___
> > 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



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

Re: [Talk-ca] Aboriginal Lands

[Paul Norman]

> From: James A. Treacy [mailto:tre...@debian.org]
> Subject: Re: [Talk-ca] Aboriginal Lands
> 
> On Mon, Feb 13, 2012 at 08:37:17AM -0600, Tyler Gunn wrote:
> > With wooded areas and lakes I've noticed we tend to just leave them
> > un-merged.  I can imagine for boundaries we'd like to have them
> > merged, especially considering they'd be spanning many tiles.
> 
> This begs the question: are there any reasons to merge areas like wooded
> areas or lakes that are broken up?
> Any reason NOT to merge them?

If you merge too many you end up with un-maintainable multipolygons that bog
down the renderer. I merge lakes but not woods since in BC the woods never
stop


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

Re: [Talk-ca] British Columbia Coastlines

[Paul Norman]

I can't speak for the other areas in any great detail, but in the lower
mainland the GeoBase coastline isn't bad from what I've seen, it's just that
there have been active users improving the coastline from Bing imagery, or
higher quality imagery. In terms of data sources for the coastline, I know
that Surrey has good accuracy up to date data for all the waterways
(available as PDDL). Vancouver and North Vancouver might, but I haven't
investigated in any detail because their datasets are not available under an
open license. 

If you're looking at priorities for water-related features, I'd suggest
streams as a higher priority. A lot of the streams in the NHN appear to be
paved over, although this may of improved since I last looked. I talked to a
friend who does urban stream cleanup work, and the cities are the only
potential datasource for more accurate data, the province doesn't have any.

> -Original Message-
> From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]
> Sent: Monday, February 13, 2012 6:00 AM
> To: Paul Norman; talk-ca@openstreetmap.org
> Subject: RE: [Talk-ca] British Columbia Coastlines
> 
> Amazing task!
> 
> And I understand that we should eventually have a look in Greater
> Vancouver, Victoria, Nanaimo and Sidney area for better data.
> 
> Cheers,
> Daniel
> 
> -Original Message-
> From: Paul Norman [mailto:penor...@mac.com]
> Sent: February 13, 2012 03:00
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] British Columbia Coastlines
> 
> For the last couple of weeks I have been replacing the portions of the
> BC coastline which were PGS or CT-dirty imports with the latest
> CanVec/GeoBase data. I elected to use GeoBase since it's coastlines
> require less manual processing to get into workable form. This process
> is now finished, with the exception of the basins that are in the US and
> have data in GeoBase and the 08OA000 and 08OB000 basins (Haida Gwaii)
> which are in progress.
> 
> Before replacing any coast, I compared it with the GeoBase data for
> accuracy. For most of BC's 25000 km of coastline the data was PGS data
> and easily replaced. The only places where there was substantial
> coastline retained were in Greater Vancouver, Victoria, Nanaimo and
> Sidney. The quality of the OSM coastline data exceeds that of
> GeoBase/CanVec in these areas.
> 
> All the data was run through JOSM's simplify function with a max-error
> of 1.5m. On later runs, short ways were combined into larger ones after
> simplification. The search expression "(parent child selected | parent
> selected) nodes:-1000" was used in doing this.
> 
> In the process I identified many unmapped rivers where I needed to join
> two sections of coastline together. Where bing imagery showed a river, I
> added a brief tracing. Most of the bing imagery was low-resolution
> Landsat or higher-resolution imagery from the BC government, the same as
> is found on their openmaps WMS server.
> 
> In the process, I ran JOSM's validator tool over most of the coastline
> and fixed other unrelated errors.
> 
> Statistics:
> The .osm files were 232 MB on disk before simplification The total
> number of objects uploaded is approximately 1.5 million Surprisingly, no
> errors were found by coastcheck in the coastline, indicating my
> procedures worked There are 47 NHN basins with coastline, varying in
> complexity and size from 5k nodes before simplification to 150k nodes
> before simplification
> 
> 
> ___
> 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

Re: [Talk-ca] Administrative Boundary

[Paul Norman]

>From the wiki, those look consistent with what I’ve seen locally, although
naturally I can’t comment about Quebec.

 

From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] 
Sent: Monday, February 13, 2012 5:54 AM
To: Paul Norman; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Administrative Boundary

 

Bonjour Norman,

 

ISO Level 7 (Upper municipality) refers to an administrative area like the
County of Peterborough (ON), while the ISO Level 6 (Municipal Regional)
refers to an administrative area like Eastern Townships in Québec (a group
of county - a level that exist only in Québec)

 

Regards,

Daniel

  _  

From: Paul Norman [mailto:penor...@mac.com] 
Sent: February 9, 2012 17:15
To: Bégin, Daniel; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Administrative Boundary

Can you give an example of a municipal regional or upper municipality?
Looking at the global usage, admin_level=5 is seldom used. I would think
that Municipal Regional would be 6 and upper municipality would be 7, but I
can’t really say without examples.

 

I would also suggest that these features in the .osm file not be closed –
just have the boundary, don’t handle it like lakes where you have multiple
areas you need to join where they cross tile bounds.

 

From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] 
Sent: Thursday, February 09, 2012 1:39 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Administrative Boundary

 

Bonjour again! 

Available administrative boundary will be included in the next release of
Canvec.osm.  From the wiki, here is the tagging values I'm going to use…

Municipal Regional:  boundary=administrative; admin_level=5 
Upper municipality:  boundary=administrative; admin_level=6 
Municipality:boundary=administrative; admin_level=8 

 <http://wiki.openstreetmap.org/wiki/Admin_level>
http://wiki.openstreetmap.org/wiki/Admin_level (Canada) 

 

Municipality admin_level=8 corresponds to gdf order in ISO standard. 
  
Municipal Regional Area and Upper Municipality (admin_level=5 and 6) are
different from what the ISO standard says (gdf order=6 and 7). Is someone
can confirm that admin_level=5 and 6 is really what is expected?

Thanks again 

Daniel Bégin 
Centre d'information topographique de Sherbrooke 
Topographic Information Center of  Sherbrooke
Ressources Naturelles Canada / Natural Ressources Canada
2144, rue King Ouest, bureau 010
Sherbrooke (Québec) J1J 2E8
(819) 564-5600 ext.242, dbe...@nrcan.gc.ca 

 

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

Re: [Talk-ca] Administrative Boundary

[Paul Norman]

The levels in your initial email

 

> Available administrative boundary will be included in the next release of
Canvec.osm.  From the wiki, here is the tagging values I'm going to use…

> Municipal Regional:  boundary=administrative; admin_level=5 

> Upper municipality:  boundary=administrative; admin_level=6 

> Municipality:boundary=administrative; admin_level=8

 

 

From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] 
Sent: Tuesday, February 14, 2012 12:07 PM
To: Paul Norman; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Administrative Boundary

 

Hi Paul, 

are you saying that I should use ...

 

ISO value for admin_level (6 & 7 - actually what is used in the GeoBase
product), or

what is identified in the wiki (5 & 6)
http://wiki.openstreetmap.org/wiki/Admin_level 

 

Question mark!

 

Daniel

 

 

 

  _  

From: Paul Norman [mailto:penor...@mac.com] 
Sent: February 14, 2012 14:57
To: Bégin, Daniel; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Administrative Boundary

>From the wiki, those look consistent with what I’ve seen locally, although
naturally I can’t comment about Quebec.

 

From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] 
Sent: Monday, February 13, 2012 5:54 AM
To: Paul Norman; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Administrative Boundary

 

Bonjour Norman,

 

ISO Level 7 (Upper municipality) refers to an administrative area like the
County of Peterborough (ON), while the ISO Level 6 (Municipal Regional)
refers to an administrative area like Eastern Townships in Québec (a group
of county - a level that exist only in Québec)

 

Regards,

Daniel

  _  

From: Paul Norman [mailto:penor...@mac.com] 
Sent: February 9, 2012 17:15
To: Bégin, Daniel; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Administrative Boundary

Can you give an example of a municipal regional or upper municipality?
Looking at the global usage, admin_level=5 is seldom used. I would think
that Municipal Regional would be 6 and upper municipality would be 7, but I
can’t really say without examples.

 

I would also suggest that these features in the .osm file not be closed –
just have the boundary, don’t handle it like lakes where you have multiple
areas you need to join where they cross tile bounds.

 

From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] 
Sent: Thursday, February 09, 2012 1:39 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Administrative Boundary

 

Bonjour again! 

Available administrative boundary will be included in the next release of
Canvec.osm.  From the wiki, here is the tagging values I'm going to use…

Municipal Regional:  boundary=administrative; admin_level=5 
Upper municipality:  boundary=administrative; admin_level=6 
Municipality:boundary=administrative; admin_level=8 

 <http://wiki.openstreetmap.org/wiki/Admin_level>
http://wiki.openstreetmap.org/wiki/Admin_level (Canada) 

 

Municipality admin_level=8 corresponds to gdf order in ISO standard. 
  
Municipal Regional Area and Upper Municipality (admin_level=5 and 6) are
different from what the ISO standard says (gdf order=6 and 7). Is someone
can confirm that admin_level=5 and 6 is really what is expected?

Thanks again 

Daniel Bégin 
Centre d'information topographique de Sherbrooke 
Topographic Information Center of  Sherbrooke
Ressources Naturelles Canada / Natural Ressources Canada
2144, rue King Ouest, bureau 010
Sherbrooke (Québec) J1J 2E8
(819) 564-5600 ext.242, dbe...@nrcan.gc.ca 

 

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

Re: [Talk-ca] Aboriginal Lands

[Paul Norman]

I'm not so concerned with the aboriginal lands as with municipal boundaries.
Aboriginal lands are unlikely to span multiple sub-tiles unless they lie on
an edge, but cities often cover several sub-tiles. 

Is converting the boundaries from polygons to linestrings an option?

> -Original Message-
> From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca]
> Sent: Tuesday, February 14, 2012 5:56 AM
> To: 'Bégin, Daniel'; talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Aboriginal Lands
> 
> If the Aboriginal lands are easily available from another source
> (GeoBase) and including them in Canvec.osm is going to make the data
> more complex I think the aboriginal lands should be excluded from
> Canvec.osm.
> 
> --
> Bernie Connors, P.Eng
> Service New Brunswick
> (506) 444-2077
> 45°56'25.21"N, 66°38'53.65"W
> www.snb.ca/geonb/
> 
> -Original Message-
> From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]
> Sent: Tuesday, 2012-02-14 09:05
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Aboriginal Lands
> 
> Bonjour All,
> 
> Paul propose not to include aboriginal lands in the next Canvec.osm
> release.
> 
> I would like to have more feedback from the community before excluding
> it :-) Regards,
> 
> Daniel
> 
> -Original Message-
> From: Paul Norman [mailto:penor...@mac.com]
> Sent: February 13, 2012 18:55
> To: Bégin, Daniel
> Cc: talk-ca@openstreetmap.org
> Subject: RE: [Talk-ca] Aboriginal Lands
> 
> Then I don't think they should be included in canvec.osm
> 
> > -Original Message-
> > From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]
> > Sent: Monday, February 13, 2012 6:04 AM
> > To: Paul Norman
> > Cc: talk-ca@openstreetmap.org
> > Subject: RE: [Talk-ca] Aboriginal Lands
> >
> > Bonjour again Paul,
> >
> > An example is not yet available but yes, it will form closed area
> > split like large lake.  That is a limitation of the Canvec.osm product
> > for the moment :-(
> >
> > Daniel
> >
> > -Original Message-
> > From: Paul Norman [mailto:penor...@mac.com]
> > Sent: February 13, 2012 05:35
> > To: Bégin, Daniel; 'Tyler Gunn'; talk-ca@openstreetmap.org
> > Subject: RE: [Talk-ca] Aboriginal Lands
> >
> > Does this mean that they would form closed areas split like large
> > lakes are?
> > If so, this makes them unsuitable for importing into OSM without
> > significant work.
> >
> > Can we see an example area so that we know what you are proposing?
> >
> > > -Original Message-
> > > From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]
> > > Sent: Thursday, February 09, 2012 1:54 PM
> > > To: Tyler Gunn; talk-ca@openstreetmap.org
> > > Subject: Re: [Talk-ca] Aboriginal Lands
> > >
> > > Bonjour Tyler,
> > >
> > > Aboriginal Lands are already available in shape and gml format on
> > > GeoBase website. It provides a dataset for the entire country.
> > >
> > > The Canvec product is produced on 50K map sheet coverage. The
> > > Aboriginal Lands, if provided through Canvec.osm product, will
> > > complied to the 50K map sheet coverage.
> > >
> > > Best regards,
> > > Daniel
> > >
> > > -Original Message-
> > > From: Tyler Gunn [mailto:ty...@egunn.com]
> > > Sent: February 9, 2012 16:38
> > > To: talk-ca@openstreetmap.org
> > > Subject: Re: [Talk-ca] Aboriginal Lands
> > >
> > > > It is possible to include Aboriginal Lands in the next release of
> > > > Canvec.osm. However, I'm trying to find a consensus in the
> > > > community concerning the tags/values to use?
> > > > I've found some links to...
> > > > - boundary=administrative; admin_level =aboriginal_land
> > > > - boundary=administrative; admin_level =2 to 4
> > > > - boundary=protected_area; protect_class=24
> > >
> > > I'm curious how this information would be represented given the
> > > distribution of CanVec data in a tiled format?   Given that
> > > administrative boundaries tend to span larger areas, I don't know if
> > > it would make sense to split these at tile boundaries.  Were you
> > > thinking to provide these boundaries in a separate file of sorts?
> > >
> > > How these boundaries are represented should perhaps be driven from
> > > where they fit into the overall picture in terms of how Canada is
> > split

[Talk-ca] BC Highway tagging

[Paul Norman]

In BC we have remarkably consistent road tagging. Unfortunately, it bears
little resemblance to what the wiki suggests. Being familiar with the
tagging, I propose changing the wiki to match practice. Call it
anti-wiki-fiddling.

I've drafted what I propose using at
http://wiki.openstreetmap.org/wiki/User:Pnorman/BC_Tagging

I've left some of the designations blank for remote areas since they are not
commonly used.

Comments are welcome. The point of this is not to change tagging, but to
document tagging.


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

[Talk-ca] Coastline in 082L10.0.1

[Paul Norman]

Aside from the usual oddities, the coastline in 092L10.0.1.osm seems odd up
in unique ways. There's a multipolygon with natural=coastline and the
coastline is ways in the MP with the role inner. If you were to try to
interpret this, it would be an area with the inside being the water.


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

Re: [Talk-ca] Closed Road Tagging

[Paul Norman]

If they were doing work on it I’d suggest highway=construction. If they’ve
just closed it indefinitely then I’d say access=no is the best way, but is
it really a primary if it’s closed until further notice?

 

Access=no should likely be rendered at lower zooms when on major road types

 

From: Daniel Begin [mailto:jfd...@hotmail.com] 
Sent: Saturday, February 25, 2012 1:33 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Closed Road Tagging

 

Bonjour,

 

There is an primary road (ref=112) around here that have been closed for two
year - authorities detected cracks in the pavement that was suggesting that
the road was sliding toward a large mining pit. All traffic is divert toward
Vimy Ridge since then.

 

http://www.openstreetmap.org/?lat=46.0167

&lon=-71.3602&zoom=13&layers=M

 

I know that we don't map/tag for the renderer but it is not obvious that the
road can't be used looking at Mapnik, Osmarender or Transport Map.  Is there
something else I can use to make it more obvious?

 

Here is how it is tagged at the moment...

highway: primary

ref: 112

access: no

note: Closed - Landslide warning / Fermée - Risque de glissement de terrain

 

I also added barriers at the end of closed segment.

barrier: block

bicycle: no

foot: no

 

Waiting for your suggestions

 

Daniel

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

Re: [Talk-ca] Cleanup

[Paul Norman]

> -Original Message-
> From: Richard Weait [mailto:rich...@weait.com]
> Sent: Wednesday, February 29, 2012 5:56 PM
> To: Talk-CA OpenStreetMap
> Subject: Re: [Talk-ca] Cleanup
> 
> On Wed, Feb 1, 2012 at 2:36 PM, Richard Weait  wrote:
> > On Mon, Jan 30, 2012 at 2:27 PM, Richard Weait 
> wrote:
> >> The first pass on the clean up started a few hours ago.
> >
> > It's complete now.
> 
> The summary of the bulk removal is as follows:
> 
> About 66% of the nodes, 70% of the highways, and 80% of the other ways
> created by these accounts were removed.  That's roughly 45% of all
> tainted nodes, 17% of all tainted highways and 71% of all other tainted
> ways.
> 
> Since the removal, a number of undecided account have been contacted and
> have agreed to the new terms.  14 of the top 22 non-agreed accounts have
> now agreed.  That is great news.
> 
> I suggest that we can have more tainted data removed automatically, so
> that we can concentrate our remapping efforts on areas that can benefit
> from human intervention.  I'd like to ask DWG to remove:
> 
> Objects edited only by those two non-agreed accounts, regardless of the
> current version number.  (Provided these  objects are not
> natural=coastline objects.)  That will remove a number of objects that
> were imported by one of these accounts and then modified by the other.
> 
> That should clear up another nice chunk of data.
> 
> I'd also like to request that DWG remove or revert all of the edits by
> another account that has not agreed.  This one has made unusual edits,
> and the user disappeared when questioned about the source of the
> information.
> 
> This is a cleanup job that nobody has tackled so far.  We might as well
> do it now.  Removing this data will clear another 18% of tainted nodes,
> 23% of tainted highways and 19% of other tainted ways.
> 
> Thoughts?

It appears that the bot is deleting ways more extensive than those proposed.
See for example http://www.openstreetmap.org/browse/way/26944782/history,
which did not meet the criteria proposed. Also, it seems to of deleted the
ways and left untagged nodes behind.

I can run a stray node cleanup later, but can we review the logic used to
remove these objects before any more are done?


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

Re: [Talk-ca] Cleanup

[Paul Norman]

> From: Richard Weait [mailto:rich...@weait.com]
> Sent: Friday, March 02, 2012 5:42 AM
> Subject: Re: [Talk-ca] Cleanup
> 
> On Fri, Mar 2, 2012 at 4:10 AM, Paul Norman  wrote:
> >> On Wed, Feb 1, 2012 at 2:36 PM, Richard Weait 
> wrote:
> >> I suggest that we can have more tainted data removed automatically,
> 
> > It appears that the bot is deleting ways more extensive than those
> proposed.
> 
> Ah, that's my fault.  I miss-stated the scope when I requested the
> removal.  The result will be the equivalent of the automated cleanup
> after the license change, for those three accounts.  I'm inclined to
> have it continue; this is making remapping faster / easier.  Apologies
> for my confusing the issue.
> 
> Last time, some nodes were cleaned up after the ways were removed.  I
> expect this will be similar.
> 
> Best regards,
> Richard

I'm not sure what the best way to proceed. Proceeding with the node removals
will still leave stray nodes as I believe there are false negatives in the
license change algorithms used. When I suggested a second run targeting
items where all versions were created by one of the accounts it was because
the first run had essentially missed some objects.

What might be best is reverting the deletion of objects that do not meet the
proposed critera, so that we can then carry on normal remapping.
Alternately, reverting the deletion of objects that are not imports or
imports of highway=secondary or above which would then allow manual
remapping to ensure continuity of the major roads network.

Proceeding with an automated node removal and including nodes that are
members of other objects could leave invalid geometries behind. I know I had
to manually check for these when removing imports prior to remapping. The
same applies to way removal and including ways that are members of
relations.


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

Re: [Talk-ca] Cleanup

[Paul Norman]

> From: Richard Weait [mailto:rich...@weait.com]
> Subject: Re: [Talk-ca] Cleanup
> 
> On Fri, Mar 2, 2012 at 12:57 PM, Paul Norman  wrote:
> >> From: Richard Weait [mailto:rich...@weait.com]
> >> Sent: Friday, March 02, 2012 5:42 AM
> >> Subject: Re: [Talk-ca] Cleanup
> >>
> >> On Fri, Mar 2, 2012 at 4:10 AM, Paul Norman  wrote:
> >> >> On Wed, Feb 1, 2012 at 2:36 PM, Richard Weait 
> >> wrote:
> >> >> I suggest that we can have more tainted data removed
> >> >> automatically,
> >>
> >> > It appears that the bot is deleting ways more extensive than those
> >> proposed.
> >>
> >> Ah, that's my fault.  I miss-stated the scope when I requested the
> >> removal.  The result will be the equivalent of the automated cleanup
> >> after the license change, for those three accounts.  I'm inclined to
> >> have it continue; this is making remapping faster / easier.
> >> Apologies for my confusing the issue.
> >>
> >> Last time, some nodes were cleaned up after the ways were removed.  I
> >> expect this will be similar.
> >>
> >> Best regards,
> >> Richard
> >
> > I'm not sure what the best way to proceed.
> 
> I think that it is.  We're just a few weeks ahead of everybody else.

I see five issues with it.

1. The changesets to remove the nodes will be much larger than the
changesets so far which have not dealt with nodes. Backing out is quicker
than proceeding;

2. The removal makes remapping much more difficult. Since the changesets I
have stopped all remapping on the island since I no longer known what needs
to be added to replace missing data or data that will be removed. Previously
I was working on the island because it took much less time per square km and
much less time per object to remap. It's much slower now, so I've given up
on cleaning up the island.

3. Concern was expressed in the rebuild@ conference call about the method of
removing areas of data and not replacing them. I'm not sure I share this
concern, but I don't know if there's a consensus on the matter.

4. Concerns over deficiencies in the algorithm, which I'll get into below.

5. People are still discussing refinements to the algorithm on rebuild@. For
example,
http://lists.openstreetmap.org/pipermail/rebuild/2012-March/99.html is
discussing a less conservative approach to some tag changes.

6. Not all of the objects removed needed to be removed. I was adding
odbl=clean as appropriate. I can't do this anymore.
 
> > Proceeding with the node removals
> > will still leave stray nodes as I believe there are false negatives in
> > the license change algorithms used.
> 
> Do you have examples so that the algorithm and process can be checked?
> 
> > When I suggested a second run targeting items where all versions were
> > created by one of the accounts it was because the first run had
> > essentially missed some objects.
> 
> Did you present examples to check?  Again, if the process or algorithm
> can be improved, perhaps we should woork towards that?

I have two separate concerns, false negatives and stray nodes.

I see two ways for false negatives to arise. The first is when a way and the
nodes that form it is created by a decliner then another mapper drags or
rotates the way to correct an offset. This can be done without retracing the
way, particularly if it's the decliner traced from a source with a known
consistent offset. The second way for a false negative to arrive is when an
object from a decliner (most likely a POI node) is retagged by a bot like
xybot. Xybot runs automatically and I don't see how it can create remove old
IP and create new IP by an automated retagging.

The second concern is stray nodes. These could occur through false
negatives, but with the algorithm used they can occur even without false
negatives.

Suppose a decliner creates a tagged way and an acceptor later adds new nodes
to refine the geometry untagged nodes with untagged nodes, no tag changes to
the object, and no moves to existing nodes. The way is then removed, but the
nodes created by the acceptor remain. This is fine from a legal standpoint,
but it leaves these nodes as stray nodes unless they are the child of some
other object.


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

Re: [Talk-ca] [Talk-us] The vandalism has begun

[Paul Norman]

Frederik, can we get these reverted? I'd do it myself but I'm not confident
enough with the revert tools and I doubt this changeset will revert cleanly.

In the particular example of way 44925685, a quick look shows no tags that
could not be recovered with TIGER and odbl=clean.

As an aside, wasn't the view expressed on the rebuild conference call to go
with a v0 concept for ways, in which case parts of the tagging would remain
on the 1st?


> -Original Message-
> From: Nathan Edgars II [mailto:nerou...@gmail.com]
> Sent: Sunday, March 11, 2012 1:59 AM
> To: OpenStreetMap talk-us list
> Subject: [Talk-us] The vandalism has begun
> 
> Even before April Fools:
> http://www.openstreetmap.org/browse/changeset/10842511
> 
> I love how portions of US 2, US 83, and US 95 are now in Canada.
> http://www.openstreetmap.org/?lat=48.562&lon=-112.387&zoom=11&layers=M
> http://www.openstreetmap.org/?lat=48.812&lon=-101.089&zoom=11&layers=M
> http://www.openstreetmap.org/?lat=46.5966&lon=-116.9202&zoom=12&layers=M
> 
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us


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

[Talk-ca] Bug in canvec street names

[Paul Norman]

In 092G03.2.2.1.osm I noticed streets named "East  51st Avenue" with two
spaces between East and 51st.

Additionally most of the lanes are tagged highway=service lanes=1
surface=unpaved but are paved, and should also have service=alley. They're
also over-noded. This may be an issue with the underlying NRN data.

I've been fixing the NRN alleyways as I do license cleanup.


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

[Talk-ca] Proposed mechanical edits: GeoBase/CanVec Service Surface and GeoBase/CanVec name spaces

[Paul Norman]

The GeoBase and CanVec imports in the lower mainland suffered from two
tagging errors I propose fixing with two one-time mechanical edits.

1. surface=unpaved service ways

GeoBase and CanVec highway=service ways are mis-tagged with surface=unpaved
regardless of if they are paved or not. I propose removing this tag as it is
misleading. To avoid removal of this tag where a mapper has reviewed it, I
will only do the obvious cases automatically and review the others.

The obvious case is ways where none of the tagging has changed since the
import with the possible exception of geobase:uuid which may have been
combined with the value from another way in a merge.

These will be identified by the tags attribution=GeoBaseR
geobase:acquisitionTechnique=Orthophoto geobase:datasetName=NRN:British
Columbia geobase:uuid=* source=Geobase_Import_2009 surface=unpaved
highway=service

2. Double-spaced names

GeoBase and CanVec sometimes have names with two spaces in them. For
example, "West  70th Street". I propose fixing these. Unfortunately this is
less automated and will require searching through the road network with JOSM
for name:"  ". 

The edit will be from my imports/mechanical edit account and appropriately
documented.

As these edits will require touching a large number of roads I also propose
cleaning up unnecessary meta-information from the import that is duplicated
by other tags. For example, geobase:datasetName=NRN:British Columbia can be
inferred from source=Geobase_Import_2009, being located in BC, and matching
highway=*.

It is not worth creating a new version of objects solely to remove these
tags, but since fixing the tagging requires creating a new object anyways it
is worth doing it in this case.


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

Re: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec Service Surface and GeoBase/CanVec name spaces

[Paul Norman]

Not listed in this message was the area this would be over. This would only
be over the lower mainland unless requested for another area.

> -Original Message-
> From: Paul Norman [mailto:penor...@mac.com]
> Subject: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec Service
> Surface and GeoBase/CanVec name spaces
> 
> The GeoBase and CanVec imports in the lower mainland suffered from two
> tagging errors I propose fixing with two one-time mechanical edits.
> 
> 1. surface=unpaved service ways
> 
> GeoBase and CanVec highway=service ways are mis-tagged with
> surface=unpaved regardless of if they are paved or not. I propose
> removing this tag as it is misleading. To avoid removal of this tag
> where a mapper has reviewed it, I will only do the obvious cases
> automatically and review the others.
> 
> The obvious case is ways where none of the tagging has changed since the
> import with the possible exception of geobase:uuid which may have been
> combined with the value from another way in a merge.
> 
> These will be identified by the tags attribution=GeoBaseR
> geobase:acquisitionTechnique=Orthophoto geobase:datasetName=NRN:British
> Columbia geobase:uuid=* source=Geobase_Import_2009 surface=unpaved
> highway=service
> 
> 2. Double-spaced names
> 
> GeoBase and CanVec sometimes have names with two spaces in them. For
> example, "West  70th Street". I propose fixing these. Unfortunately this
> is less automated and will require searching through the road network
> with JOSM for name:"  ".
> 
> The edit will be from my imports/mechanical edit account and
> appropriately documented.
> 
> As these edits will require touching a large number of roads I also
> propose cleaning up unnecessary meta-information from the import that is
> duplicated by other tags. For example, geobase:datasetName=NRN:British
> Columbia can be inferred from source=Geobase_Import_2009, being located
> in BC, and matching highway=*.
> 
> It is not worth creating a new version of objects solely to remove these
> tags, but since fixing the tagging requires creating a new object
> anyways it is worth doing it in this case.
> 
> 
> ___
> 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

Re: [Talk-ca] Wind farm access roads that really shouldn't be in OSM

[Paul Norman]

> -Original Message-
> From: Stewart C. Russell [mailto:scr...@gmail.com]
> Sent: Monday, March 19, 2012 4:22 PM
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] Wind farm access roads that really shouldn't be in
> OSM
> 
> I've notice a few ways in OSM like this one:
> 
> http://www.openstreetmap.org/browse/way/39334713
> 
> that really shouldn't be in the database. They're GeoBase imports via
> the NRN. They're not tagged in any way that would allow removal.
> 
> There is no public access on these roads. They're mostly gated closed. I
> don't know how they would have made it into the NRN.
> 
> cheers,
>  Stewart

highway=unclassified seems to mean owned by someone other than a province or
city to GeoBase, which is wrong. I'd just retag as highway=service, but it
definitely belongs in the DB if there's a road or path there, just not
tagged like it is.


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

Re: [Talk-ca] Wind farm access roads that really shouldn't be in OSM

[Paul Norman]

> -Original Message-
> From: Stewart C. Russell [mailto:scr...@gmail.com]
> Subject: Re: [Talk-ca] Wind farm access roads that really shouldn't be
> in OSM
> 
> On 12-03-19 19:45 , Paul Norman wrote:
> >
> > I'd just retag as highway=service, but it definitely belongs in the DB
> > if there's a road or path there, just not tagged like it is.
> 
> But it's not a highway, which implies access. There is no access.
> 
> The particular one I tagged, given the amount of illicit grow-ops in the
> area, would very likely get you escorted off by the OPP. If OSM has it
> shown, wouldn't it encourage attempted access?

highway=service with access=no or access=private then. Many service roads
aren't open to the public.

If the road is there and is a service road, it's mappable.


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

[Talk-ca] Township of Langley roads background layer

[Paul Norman]

I have finished my translation file for the Township of Langley roads data.

The resulting output is available at
http://maps.paulnorman.ca/langley/Roads-201204.zip

Included are the shapefiles, ogr2osm translation file, and .osm output file.

This file is not to be blindly imported, but used as another source when
mapping or tracing roads.

The spatial accuracy seems better than CanVec although CanVec also has lanes
data.

I intend to ask the TOL GIS department if they have lanes data.


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

[Talk-ca] City boundaries on the Canada/US border

[Paul Norman]

There are a significant number of cities in BC and Washington which have
borders that in practice[1] coincide with the Canada/US border. Currently in
OSM these are represented with many nearly-overlapping ways.

The Canada/US border here consists of the BC-WA border, BC-ID border, BC-MT
border, AB-MT border, SK-MT border, SK-ND border, etc. There are separate
ways for the cities on the Canada side and cities on the US side.

I am considering replacing these with one set of non-overlapping border
ways. This would involve splitting the ways whenever a city ends or begins
on either side of the border. The border would then consist of a BC-WA
border in the water, a Surrey-Whatcom County border (in the water), a White
Rock-Whatcom County border, a Surrey-Whatcom county border, Surrey-Blaine
border, Langley-Blaine border, Langley-Whatcom County border,
Abbotsford-Whatcom County border, Abbotsford-Sumas border, etc.

This would reduce the number of ways present when you download a section of
the border and have many advantages. The one big disadvantage is that it
would boost the number of ways in the Canada and US relations. This
increases the chance of conflicts and also increases the number of places it
could be broken.

Either way, the Canada/US border will remain very complex with so many
different boundary relations ending there.

If I do this, I will also align the borders to the IBC data (PD). I've
investigated the accuracy of their data, and it agrees with the markers on
the ground to within 10cm. I believe the most significant source of error in
their data is the NAD83 to WGS84 conversion.


[1]: The actual legal situation is much more complicated and serves as a
good example of the problems that arise when you define what is supposed to
be one line in multiple ways. The biggest oddity is that the Washington
border extends out of the United States into Canada. All of the other
oddities are just a few meters at most.


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