Re: [Talk-ca] Importing buildings in Canada

[Steve Singer]

On Sat, 28 Sep 2019, Nate Wessel wrote:



I for one would be happy to support a local effort to import high quality 
buildings in Toronto and/or the GTA. I
think if we can actually meet up face to face our discussions may remain a bit 
more civil and productive. Hopefully
consensus will be a bit easier to achieve with smaller groups too!

I see that the OSM Toronto meetup doesn't have any upcoming events... Would 
others in the GTA be interested in
planning a meet up to talk about a local import plan? Is anyone on the list in 
charge of organizing these?


I am one of the organizers of the OSM Toronto meetup.

I've now posted the regular monthly mappy hour meetup for the Toronto OSM 
group. I had been meaning to do this anyway.


I'm also happy to post a special event dedicated to discussing an import in 
the GTA if people are interested.







Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com

On 2019-09-28 1:03 p.m., Jarek Piórkowski wrote:

Hi all,

To be a bit more positive:

If we want to get buildings on the map, but we can't get Canada-wide
data improved by Statcan to a standard acceptable to all mappers in
Canada, IMO the best bet will be to split this into much smaller
batches and support local mappers who would be interested in getting
the data in.

In my browsing of neis-one.org statistics for Canadian mappers and the
Notes active in Canada, I've seen active mappers and small communities
in at least Halifax, Calgary, Edmonton, Vancouver, and Victoria
metros, and I might have missed some more. Many of them I have never
seen on the mailing list (which is a whole another issue), but
contacting them directly (via osm.org messages?), asking if they are
aware of other local mappers, if they would be interested in having
building data, if it is of acceptable standard to them, and if they
would be willing to help validate-and-upload the data (with help of
the central tooling) might get some success.

I hope that will go better than the previous attempt which could be
read - uncharitably - as a bunch of mailing list insiders throwing
federal data over the fence with little consultation.

It'll be a lot of work communicating and organizing. But getting
buildings is a lot of work, and if data producers can't do better,
whoever wants the buildings will have to do the work. Maybe with more
local support even the imports list will be more bearable.

Thanks,
--Jarek

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



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

Re: [Talk-ca] Toronto appreciation

[Steve Singer]

On Mon, 18 Mar 2019, Martijn van Exel wrote:


Hi all, and Toronto mappers in particular.I am currently visiting Toronto and 
using OSM
extensively to get around using maps.me and the OSM web site mainly.
The level of detail and completeness are amazing, a big thanks to all Toronto 
mappers.
I didn’t know about PATH, the level=-1 pedestrian infrastructure, which seems 
to be well mapped
also. Amazing.
If any of you are around, I have some time tomorrow in the afternoon, if you 
want to get a coffee
or a beer.
Martijn


I've posted an event to the meetup group (based on Martijn proposal) for 
Tuesday March 19, 4:00pm at C'est what.


https://www.meetup.com/OpenStreetMap-Toronto/events/259886903/

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

[Talk-ca] MSF Toronto Missing Maps Event

[Steve Singer]

I'm forwarding this on.
I attended their event last month. It was a great event and they get a lot 
of new mappers adding data.




I just wanted to send you a quick message to let you know that we are 
hosting our next public Missing Maps
mapathon on Wednesday, September 26th at the MSF Canada office (551 Adelaide 
St W), and to extend an
invitation again to you and your meetup group. The mapathon will be hosted 
by MSF staff and include
discussion about the area we will be mapping again. It is still free to 
attend, and we will be providing

pizza and refreshments.

For all the details do check out and share the Eventbrite page.

https://september-mapathon.eventbrite.ca [meet.meetup.com]­

Once again, if you have any questions please do not hesitate to ask, 
otherwise we hope to see you there!


Best,

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

Re: [Talk-ca] Building Footprint Upload to OSM

[Steve Singer]

On Wed, 7 Mar 2018, john whelan wrote:


That one says federal government.  Somewhere they have a kit with the municipal 
version and that's the one you
want.  Exact license is the one the City of Ottawa uses just sub "City of 
Ottawa" with your city name.

Note to Tracey and or Kent could you be very nice and point Rob to the exact 
municipal Open Data license 2.0 that
TB drew up.


I do not see either the open-government-license-canada or the TB open 
data license, or a Canadian "municipal data license 2.0" listed at 
https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility


My understanding is that the "City of Ottawa Open Data License 2.0" received 
special approval from the LWG. 
(https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan#Licence)


It is also my understanding that substituting "City of Ottawa" with "Region 
of Durham" would still require the LWG to approve the Durham license.


It is my understanding that the act of substitution is enough of a change to 
require the LWG to need to look at it.


I don't see open-government-licence-canada listed as a compatible 
generic license on the wiki page.


If anyone is aware of something written from the LWG that says otherwise 
please post a link.


Steve




Many Thanks John

On 7 March 2018 at 13:24, Rob Halko  wrote:

  Thanks for your help John,

   

  Is this the license we should be looking at adopting:
  https://open.canada.ca/en/open-government-licence-canada?

   

  Rob

   

  From: john whelan [mailto:jwhelan0...@gmail.com]
  Sent: Tuesday, March 06, 2018 9:22 PM
  To: Rob Halko 
  Cc: impo...@openstreetmap.org; talk-ca@openstreetmap.org; Jonathan Brown 
; Alasia,
  Alessandro (STATCAN) 
  Subject: Re: [Talk-ca] Building Footprint Upload to OSM

   

  I was involved in getting the Ottawa Open Data building outlines into OSM 
working with Stats Canada. 
  Based on that experience you need to go through some steps..


Step one concerns the license.  Regional Municipality of Durham open data 
license almost certainly has not
been approved by the LWG.  The choices are formally adopt the Treasury Board 
license for Open Data as Ottawa
has done or ask Alessandro nicely about whether Stats Can can make it available 
through the TB open data
portal.  The third choice would be submit it to the LWG.  The backlog is 
substantial and I'd expect at least
at year, possibly two before gaining approval if they thought it was perfect.

The data can also be formally given to OpenStreetMap, ie supplied but not under 
your Open data license.  I
understand Vancouver followed this route.

 

One the license is sorted out then there is a further process to follow and 
that would be tight for March
29th.

I suggest sorting out the license first.

Cheerio John

 

On 6 March 2018 at 11:05, Rob Halko  wrote:

  Good morning,

   

  The Region of Durham has recently purchased Building Footprints data for 
the entire Region, and
  it is available as Open Data: 
http://opendata.durham.ca/datasets/building-footprints

   

  We would like to import these to Open Street Map to engage the community 
and help improve the
  overall map. We are supporters of OSM and wish to regularly partner in 
improving the data.

   

  In particular, we are hosting a mapathon on March 29, which asks for 
student input to add
  attributes to the buildings based on OSM guidelines for the Building 
Canada 2020 project:
  
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020#The_data_that_could_be_mapped

   

  We have read your Import guidelines and are here to express our interest 
in contributing our
  building data. The intention is not to overwrite those buildings that the 
community has built,
  but bridge the gap to include the rest of the 200,000+ buildings in 
Durham (largely
  residential), which are missing from OSM.

   

  Please let us know how we can contribute this valuable data on behalf of 
the community.

   

  [IMAGE]

  Rob Halko | Supervisor, GIS
  Regional Municipality of Durham | Corporate Services - Information 
Technology
  905-668-4113 ext 2189 | Mobile: 289-927-7168
  Corporate Values: • Ethical Leadership • Accountability • Service 
Excellence • Continuous
  Learning and Improvement • Inclusion

   

   

THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN 
INFORMATION THAT IS
PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY 
RELEVANT PRIVACY
LEGISLATION. No rights to any privilege have been waived. If you are not the 
intended recipient, you
are hereby notified that any review, retransmission, dissemination, 
distribution, copying, conversion
to hard copy, taking of action 

Re: [Talk-ca] Brandon licensing

[Steve Singer]

On Sat, 3 Mar 2018, john whelan wrote:


> This brings me to the conclusion after all these discussions something 
similar to what SteveA-2009 mentioned.
Instead of having OSM conform to these licenses, would be be able to get the 
governing bodies to conform to OSM?
In many cases, I'm working with my colleges in the GIS community to borrow 
data,  if we could give them a
"guideline to a OSM request" document or something we might be able to leverage 
a ton of data we wouldn't already
have. I think this is one of the main motivators behind building 2020. That a 
lot of this data is accessable-ish,
opening it would only help add better data to OSM. (keeping in mind quality, 
applicability ect)

It's better if you get them to use the Treasury Board Open Data licence.  TB 
has a kit for municipalities and I
understand the licence is included.  The advantage is other organisations can 
use the open data.  If you use
something OSM specific then someone lese might run into the same problem.


Whenever I've spoken[1] to government representative about choosing an OSM 
compatible license I tell them to choose between PDDL and CC0. Use one 
of these two licenses as written, don't make any changes to them. These are 
the two licenses listed as fully compatible with both the CT and ODBL

https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility

I regard that as the guideline.  Any other licenses including custom 
licenses make things more difficult.


[1] - Everytime I've provided input into a licensing consultation in 
Canada the end result is that data is released under some other license. Not 
once has someone explained to me why either of those licenses aren't 
acceptable.



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

Re: [Talk-ca] COMS2200 Ottawa, Carleton University

[Steve Singer]

On Tue, 10 Oct 2017, Tracey P. Lauriault wrote:




Greetings OSM mappers;



For the benefit of background to others on the list

http://www.openstreetmap.org/user_blocks/1560

Is an example of the block message that was sent to a bunch of users.

(I wasn't involved in asking for or implementing the blocks or have anything 
to do with the assignment).


I haven't looked at the edits in any details but I will make a few general 
comments


1. If one user comes into OSM and makes a few changes with issues 
because of misunderstandings or inexperience fixing those changes isn't a 
big deal. Most of the time someone will just fix them without saying 
anything.  However if 30 or 300 users make lots of changes in a short amount 
of time with the same types of errors the volume present challenges.  Large 
scale edits by a bunch who are doing it as part of a course, or who are 
employed by a company to make the changes, or who are doing so as part of a 
coordinated humanitarian effort have the potential to cause problems if they 
aren't coordinated  carefully.



2. A big part of working in any open-source project particularly with OSM is 
that you need to communicate with the other contributors. Communication is a 
two way street, some people are better at it then others and it doesn't come 
naturally to everyone.  I would hope that a course that covered the 
contributing to open source projects (including open data contributions) 
covered interacting with the community. If the course only wanted to give 
students experience with the tools then editing against a test or 
development instance of OSM would be better.


The advise I would give to people new to the open source communities(and at 
times remind veterans) is believe that most people who are contributing are 
coming from a place of good intentions and to give them the benefit of the 
doubt and try to understand where they are coming from.


When contributing to an open sourced project you need to take responsibility 
(as an individual) for your contributions but that doesn't mean they need to 
be, or will be perfect. No edits are perfect but people need to be willing 
to listen to and learn from feedback from other members of the community.


Steve







I understand that students for COMS2200 have been blocked from posting to OSM.

There was also an unfortunate email sent to Carleton University by one of your 
members that is circulating
through the administration from (james2...@gmail.com).

The data are being contributed as part of an assignment described here -
https://github.com/TraceyLauriault/COMS2200A

I understand that the students are making some small and some large mistakes 
that may not meet your OSM
data quality standards.  The students are restricted to only be mapping the 
Carleton University Campus.

I wonder if it might be possible to unlock the restriction to let them finish 
the assignment.  They should
be done by next week. There are 150 students.  Once the assignment is complete 
I would gladly work with you
to salvage the data, delete some data, repair some data or wipe all of the data.

We apologize for this inconvenience and hope that you can be empathetic and 
allow for the assignment to be
completed so that the students can be assessed.

Also, perhaps there are a number of common errors and if you identify them we 
may be able to fix them.

Sincerely
Tracey

--
Tracey P. Lauriault

Assistant Professor 
Critical Media Studies and Big Data

Communication Studies
School of Journalism and Communication
Suite 4110, River Building
Carleton University
1125 Colonel By Drive
Ottawa (ON) K1S 5B6
1-613-520-2600 x7443
tracey.lauria...@carleton.ca
@TraceyLauriault
Skype: Tracey.P.Lauriault
https://carleton.ca/sjc/people-archives/lauriault-tracey/

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

Re: [Talk-ca] Ottawa Buildings & Addresses [Statistics Canada project]

[Steve Singer]

On Fri, 27 Jan 2017, Denis Carriere wrote:


Good day everyone,

Thanks for everyone who provided feedback related to the Ottawa import plan, all of 
the concerns & issues have been
resolved.

Going to officially announce that we will be starting the Ottawa building & 
address import.


I am confused about the state of the license issue still.

I haven't seen anything from LWG saying resolving the questions or saying 
that the ODL-Ottawa is compatible with OSM (What i called situation 1 in my 
email last week).


I don't really understand what these issues are but others have expressd 
concern and I think that needs to be sorted out.


The email from Robert Giggey of Jan 24 5:27pm linked to on the wiki page 
doesn't seem like a permission email for what I called situation 3.


I don't see him saying something along the lines of

"On Behalf of the city of Ottawa I hearby accept the OSM contributor terms, 
and give explicit permission for this data set to be imported into OSM"


Steve







OSM Wiki - Import Plan
https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan

Explicit Permission from the City of Ottawa
https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan#Explicit_permission

Video instruction (YouTube)
https://youtu.be/OkFCkPBR7PA

City of Ottawa's open datasets
http://data.ottawa.ca/dataset/urban-buildings
http://data.ottawa.ca/dataset/addresspoints

Tasking Manager #37 (private - invite only)
http://tasks.osmcanada.ca/project/37

Cheers,

~~
Denis Carriere
GIS Software & Systems Specialist
OSM Account: @DenisCarriere





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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Steve Singer]

On Sun, 22 Jan 2017, Stewart C. Russell wrote:


On 2017-01-22 12:48 PM, James wrote:


So why is this not considered the exact same as OGL-CA, which is
considered compatible with ODBL?


My understanding of why it's not the same:

1) The OGL-CA, due to a fault in its design, can only be used by the
Canadian Federal Government. Contrast that with OGL-UK which is written
as a general licence for any organization in the UK public sector to use.

2) The Ottawa licence has some differences, apart from the information
provider in the definitions:

- it's missing the introduction completely

- in excluding personal information, it refers to the Ontario
  Municipal Freedom of Information and Protection of Privacy Act,
  rather than the federal Privacy Act. These laws have different scopes


It isn't obvious to me why any of these changes would make the Ottawa 
license incompatible with OSM.




I'd tend to agree with Steve that if permission has been given by the
City, then I can't see any other objection. Paul Norman may have to
chime in with any remaining concerns.

I would ask those who claim that we should accept this because the
Federal government's lawyers and staff say we should: does the Federal
government have the best interests of OSM as a continuing project at
heart? One cannot rely on the opinion of other people's lawyers, because
they have different goals.



OSM as a project needs to be able to take a clear license and decide if 
using data covered from that license is safe to use without having to really 
on special permissions. If we decide that that license is incompatible for 
reason X and we need special permission then we might decide to get that.



I'm finding it hard to see why the terms of either OGL-CA or the 
Ottawa license are incompatible.





Stewart


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



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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Steve Singer]

On Sat, 21 Jan 2017, Paul Norman wrote:


On 1/20/2017 6:00 PM, James wrote:

Is OGL-CA not compatible with osm?


The license isn't OGL-CA. OGL-CA is the license from the Federal 
government, while the City of Ottawa uses the ODL. In the case of OGL-CA 
data it's compatible because they gave a statement on compatibility.


It seems to me that there are at least three situations that can crop up in 
deciding if we can use data


1) A reading of the license text allows the use with OSM.  If the text of a 
given license is compatible with the requirements of OSM then  I don't see 
why we need any additional statement.


2) The compatibility of the license is unclear because of particular terms 
of the license.  A particular government entity then gives us a statement 
saying that they feel the license is compatible with OSM.  That same 
government entity would then have a hard time coming back later and saying 
that the license isn't compatible. However it doesn't tie the hands of other 
government entities that happen to be using the same license.


3) A particular license might not be compatible with OSM but the government 
entity gives us permission to use their data.  In this case the 'permission' 
is the license.


Why doesn't the OGL 2.0 qualify as compatible under criteria 1? Is there any 
particular term in a templated OGL 2.0 that someone feels is a concern?


Replacing a  variable with 'Government of 
Canada' versus 'City of Ottawa' doesn't change the license.  we see this 
in software licenses all the time. The BSD software license reads 'Regents 
of the University of California' but changing that to the organization that 
is releasing the code doesn't make it no longer be a BSD license.


The whole point of open-data licenses is that people can use the data 
without having to get special permission from the government for each use of 
the data.  Some of the licenses used by Canadian governments in the past 
had clauses that made them not open/suitable. It isn't clear to me what the 
problem is with this license.



Steve




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




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

Re: [Talk-ca] [Import] Ottawa Buildings & Addresses [Statistics Canada project]

[Steve Singer]

On Wed, 19 Oct 2016, James wrote:


Seems like a good enough time like any other to talk about the import of Ottawa 
buildings and addresses
into OpenStreetMap.

Documentation is available here:
https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan


A few comments

* Replacing Building Geometries - I don't like the policy of replacing 
existing building geometries with imported ones.  I feel that large scale 
replacement of hand traced work with automated/imported work will discourage 
future mappers.  Also sometimes which is 'better' is a matter of opinion and 
if a few mappers are replacing hundreds or thousands of buildings in a short 
period of time it is hard to have discussion on an individual building 
basis.   I don't have issues with a mapper manually changing or replacing 
the geometries but the bulk non-traced nature concerns me. I have 
heard numerous complaints over the years from mappers who traced lakes 
manually only to see them replaced by canvec imported lakes.


* Notes - How many 'What is the address of this house?' notes do we think 
this is going to generate? Adding a few dozen notes in the Ottawa area isn't an 
issue but if this process adds hundreds of notes that require manual survey 
then I'm not sure that is better than just skipping the address(but 
this could be discussed)


I think the import plan needs to talk more about what the expected 'quality' 
is. I am not talking about the quality of the data but the quality of the 
merging


For example:
* Do we expect that before uploading a tile all JOSM validator errors get 
cleared on the objects being uploaded?
* If an existing object such as a road, alley or stream runs through the 
geometry of the building then will the pre-upload validation process require 
that this be fixed



Part of the problem with the Canvec imports is that quality is very much a 
factor of who imported a tile in a particular area.  We never really came up 
with minimum standards for the validation and repair requirements. I think a 
checklist of specific types of problems that we expect will need 
correcting/validating by the person uploading the tile would help



The plan also talks about using post upload validation tools like Osmose.

Is the proposed workflow something along the lines of
1) Grab a .osm tile with buildings
2) Work in JOSM to address any issues the importer finds by eyeballing 
things or using the validator

3) Upload
4) Pick another tile repeat
5) Once there are no more tiles left check Osmose and other tools

I think it would be better to fix all the issues with the footprints in the 
first tile before moving onto a second tile.


Are there examples of tasking manager coordinated building imports that the 
community considers a success? If so how does this plan compare to what has 
worked well. (This isn't specifically directed at James)




I haven't yet looked at samples of the .OSM files


Steve





Discussion with local mappers has happened in person for multiple 
months(community buy in is very high in
these meetings and we all saw benefit in including this data) :
https://www.meetup.com/openstreetmap-ottawa/

Once positive discussion of a period of 2 weeks has been met, we would like to 
start the import of said
data.

Thank you.






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

Re: [Talk-ca] Bulk Import of Address Range in GTHA from Metrolinx, Second attemps

[Steve Singer]

On Wed, 10 Feb 2016, Mojgan Jadidi wrote:

For accuracy and consistency issue, as I mentioned we validate our result 
with imagery data and geosbase road segment geometry following with an 
extensive visual inspection. Our visual inspection is on-going step and 
never stops!.


What is the plan for when an inspection notices an issue.
In the brief period when the import was in OSM I noticed some places where 
there duplicate address ways or ways inconsistent with the existing roads. 
Sometimes this was because the existing data in OSM was properly in need of 
updating. How does that fit in with your process?


I feel that consistency with adjacent data is more important that absolute 
spatial accuracy.  For example if your adding addresses to for a road that 
is already in OSM but shifted east 10 meters compared to the 
Geobase/statscan geometries then the address way should also be shifted east 
(unless the correct thing to do is to adjust the OSM road)


We don't want something like


---odd addr way for Main Street---

---even addr way for Main Street ---

* road for Main Street **


For the tile by tile Canvec imports the merging was a manual process and 
better importers corrected issue like this using their best judgement and 
the various available sources.  This took time though, and if your adjusting 
the OSM data to get things inline then you need to upload that area as your 
doing the adjustments not later.



Steve





Mojgan (Amaneh) Jadidi, Ph.D.
Intern, Applied Research & Corporate Monitoring
Planning & Policy | Metrolinx | 97 Front Street West, Toronto, ON, M5J 1E6 | T: 
416-202-5844

Postdoctoral Research Fellow
GeoICT Lab | York University | 4700 Keele St, Toronto, ON, M3J 1P3

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

Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1

[Steve Singer]

On Tue, 2 Feb 2016, Mojgan Jadidi wrote:

Mojgan,

We did say at MappyHour last month that OSM was filled with well intentioned 
imports gone bad. Don't feel bad you seem to be well intentioned and many 
others before you have made mistakes in the import process.


I don't think the advice you got at the meeting was to go rush ahead and 
start importing. I think the advice you received was more along the lines of 
"imports are really hard, getting community consensus is even harder", 
"spend some time understanding how the OSM community works first", "use 
dedicated import accounts attached to individuals not an organization"


Some specific feedback I have on the import

1) I think it is critical that you do the data validation and checking 
*before* uploading to OSM.  This is what I thought you had described but I 
must have misunderstood.  The reason why it is better to do the cleanup 
before uploading the data to OSM is because this way no bad data is sitting 
in OSM until someone gets around to cleaning it up.  The community also 
likes this better because we don't have to worry about if you will ever get 
around to cleaning it up


The flow I would recommend is along the lines
1) Person takes a small area of generated address points
2) They download the current OSM data and check for problems
3) They fix any issues and upload the small area they just checked

The changesets on Monday appeared to be uploading everything first.


2) You should publish your generated files for review(or at least a sample). 
In some areas I spot checked last night I saw nodes with no tags and not 
connected to an interpolation way.  This might have been an artifact of a 
in-progress revert, I'm not sure.


I also saw some places where the existing OSM roads and address 
interpolations were a bit offset from the stuff you uploaded and this 
resulted in duplicate address ways (the existing geometry in OSM might not 
be from a rough survey). Manual cleanup would be required.



3) I am not sure if we need the :source tag on each node or if putting it on 
the changeset would be enough.  Earlier imports tended to put metadata on 
each node but I think we have been trying to move away from this.



Steve



Hi all,Please accept my apology for this misunderstanding, I thought our 
presence for last OSM meeting and
flowing emails in Talk-ca and with John were part of communication and 
discussion, we launched our wikipage
two weeks ago, and we did not receive any feedback, so we thought to start 
import via JOSM. 

as we expalined in our wikipage, we created the algorithm to detect the missing 
information, and then we
check the quality of this information on JOSM on the top of OpenStreetMap, Bing 
Areal imagery, GeoBase Road
network and some local municpal open data. the data is created initially 
through StatCan, however, we noticed
the low quality of StatCan road segment geometry, so we deal with this issue by 
using complement dataset such
as OpenStreetMap, Bing Areal imagery, GeoBase Road network and some local 
municpal open data. all created
nodes and ways are carefully inspected visually using above dataset for more 
that 6 weeks. 

Our final verification will be on the OSM server (on-line) to avoid or detect 
any issues. Our aim is having
high quality address information in OSM for sake of community. we were very 
prudent from the first step to
have a high quality source of information. 

I hope that the community will accept our contribution and enjoy to use the 
data.

Best regards,

Mojgan  
  

Mojgan (Amaneh) Jadidi, Ph.D.
Postdoctoral Research Fellow
GeoICT Lab
York University
Toronto

ca.linkedin.com/pub/mojgan-amaneh-jadidi/10/825/969/

On 2 February 2016 at 07:00,  wrote:
  Send Talk-ca mailing list submissions to
          talk-ca@openstreetmap.org

  To subscribe or unsubscribe via the World Wide Web, visit
          https://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. Triplinx import (Stewart Russell)
     2. Re: Triplinx import (john whelan)
     3. Re: Triplinx import (Stewart Russell)


  --

  Message: 1
  Date: Mon, 1 Feb 2016 18:36:01 -0500
  From: Stewart Russell 
  To: talk-ca 
  Subject: [Talk-ca] Triplinx import
  Message-ID:
          

Re: [Talk-ca] Urgent care centre

[Steve Singer]

On Mon, 30 Nov 2015, Andrew MacKinnon wrote:


How do you tag an urgent care centre? (An urgent care centre is a
non-24 hour health care facility for less severe health problems.
Typically they are former emergency rooms).

I want to prevent an incident like this happening:

A shooting victim mistakenly went to what is now an urgent care centre
(was a hospital) near Jane & Finch and died.

I changed the former location of Humber River Regional Hospital to
amenity=clinic, emergency=no from amenity=hospital, emergency=no. I
don't want hospitals without emergency rooms to show up in a search
for "hospital".


I don't disagree with changing the tagging of the former Humber River 
Hospital(just like we need to remember to update the tagging on 
Oaville-Trafalgar hopsital when it moves on the 13'th)


There are other active hospitals that don't have an emergency 
room, ie http://www.openstreetmap.org/way/43804629 since those are hospitals 
I think the tag is proper.













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



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

Re: [Talk-ca] OSM data quality in Canada

[Steve Singer]

On Wed, 17 Jun 2015, Martijn van Exel wrote:

Hi Andrew, 


Thanks for elaborating on the CanVec / Geobase imports! This also raises new 
questions.. See below.


On Jun 17, 2015, at 3:00 PM, Andrew MacKinnon andrew...@gmail.com wrote:

A lot of the data in Canada was imported from CanVec and Geobase,
some of it by me several years ago. The imported data is pretty poor
quality in many places. I haven't done much work on this recently, as
imports have a bad reputation in OSM and I am mostly concerned with
surveying. For example:

- Some older road data comes from an import which combined CanVec and
Statistics Canada road names, attempting to match the road names in
Statistics Canada with roads without names from CanVec, and this data
is poor quality.


Is this described in more detail anywhere? Are the data / scripts / 
process still available? Which dat was poor quality, CanVec or Statistics 
Canada?


The StatsCan geometries were really poor at least as bad as the original 
TIGER stuff but they were the only source of road names in some places.


The scripts used for the geobase-osm (and attaching statscan names) are 
available at 
http://svn.openstreetmap.org/applications/utils/import/geobase2osm

I only did this in Alberta and Ontario.

We tried to use roadmatcher to only include road segments that we were 
pretty sure didn't already exist in OSM.  This often left gaps in road 
segments where roadmatcher wasn't sure if something was or wasn't included. 
Also we didn't have any way of automatically attaching the existing OSM 
ways with the new geobase ways which left A LOT of unconnected roads.  This 
has mostly been fixed (often thanks to keeprite and maproulette) but it 
tooks many years.


Some of the initial sections also didn't connect new geobase roads with each 
other due to a bug the import script, we tried to fix this with repair 
scripts at the time.



Steve


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

[Talk-ca] Municipal data source attribution

[Steve Singer]

What is the current procedure for meeting the attribution requirement of a 
municipal data-source released under the 'Open Government Licence ?


Do I just need to add the source to the list at 
https://wiki.openstreetmap.org/wiki/Contributors ?



I would like to take some of the data for Oakville released 
http://oakville.ca/data/catalogue.html , licensed under 
http://oakville.ca/data/open_data_licence.html. My understanding is that 
this is the Canadian OGL only v2.0 changed to list 'Town of Oakville' as the 
copyright holder instead of the crown.


I am NOT planning an import, at this time, or any automated conversion of 
the shapefiles to OSM files. I am planning on using the data files as a 
source to pick up some missing names of things (parks , some trails etc).


Steve


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

Re: [Talk-ca] Open Government Licence

[Steve Singer]

On Tue, 24 Sep 2013, Paul Norman wrote:


From: Matthew Buchanan [mailto:matthew.ian.bucha...@gmail.com]
Sent: Tuesday, September 24, 2013 3:59 PM
To: OSM Talk-ca
Subject: [Talk-ca] Open Government Licence

Is this good news for OSM?


I'll be doing a full analysis later, but I believe the license is
currently incompatible with OSM because of a drafting error on the
cities' part.


Is this a drafting error on Vancouver's part or is the error in
the Open Government license text that all these governments are using as 
their template? (http://data.gc.ca/eng/open-government-licence-canada ?)





Acknowledge the source of the Information by including any
attribution statement specified by the Information Provider(s)
and, where possible, provide a link to this licence.



If the Information Provider does not provide a specific
attribution statement, or if you are using Information from
several Information Providers and multiple attributions are
not practical for your product or application, you must use
the following attribution statement:

Contains information licensed under the Open Government Licence -

Vancouver.

It also defines Information Provider as the The City of Vancouver

OSM can only guarantee attribution in accordance with 4.2 of the
ODbL. This would be okay with the attribution required for
several Information Providers except that the only Information
Provider is the The City of Vancouver, and as there is only one
City of Vancouver, there is never a scenario where there are
multiple Information Providers.


Wouldn't the  multiple Information Providers kick is as soon as you 
combined data from Vancouver with any other source such as the existing OSM 
database?






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




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

Re: [Talk-ca] Importations Canvec

[Steve Singer]

On Sun, 23 Jun 2013, dega wrote:



Depuis plusieurs mois, je me retiens d'exposer mes réticences à propos des
importations massives de Canvec.
Moi, et plusieurs autres, considérons que les données Canvec sont imprécises,
désuètes et/ou incomplètes et que cela cause problème aux collaborateurs OSM.
Le sujet de l'heure, sur talk-ca, concernes les licenses et attributions. J'en
profite pour exposer une facette de mes réticences à propos de Canvec.


snip


Le but de mon intervention est d'exposer les questions suivantes:

- lorsqu'on modifie un obget Canvec, que doit-on faire des balises source,
attribution et UUID?


Je croire courant etas qui acceptable de supprimer les source, 
attribution et UUID quand modification. Recent  imports generalement 
excluent ces balises a quel moment discute sur impo...@openstreetmap.org


--
(what I hope I am saying is) I think current practices say that it is 
acceptable to remove the source, attribution and UUID tags when modifying 
objects. Recent imports have been excluding this type of tag from objects 
when discussed on impo...@openstreetmap.org






- Les membres d'OSM ont tous la permission et le devoir d'améliorer l'état de
la carte et, lorsqu'on le fait, je ne vois pas pourquoi on devrait préserver
les balises Canvec (ou Geobase ou autre).

- si la communauté accepte que ces balises n'ont pas à être préservées,
pourrait-on demander aux importateurs NRC de ne pas les insérer. Quand je veux
connaître le créateur d'un objet, j'uitlise la fonction historique et c'est
dans l'historique que NRC devrait signaler sa contribution.

Quel est votre avis, svp?



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



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

Re: [Talk-ca] Actual OpenStreetMap Birthday Party Thread

[Steve Singer]

On 06/11/2013 03:46 PM, Richard Weait wrote:

:-)

So, previous (Toronto) OSM Birthday parties / anniversaries have been 
social affairs, with food and drink and unstructured conversation.  
Usually (exclusively, to date ?) at a private residence.


Any thoughts about continuing on those points, or changes refinements 
that you'd like to enable?




An event that involves some actual surveying has some appeal to me.  
Maybe something targeted at getting the many of regulars at the 
mappy-hours to get back into mapping/surveying.  A number of regulars at 
the mappy-hours once did a lot of mapping but haven't recently.  I'd 
like to get them back into mapping, they still show up somewhat 
regularly at the events.


Also.  If you have attended one or more of these events, what would 
you want to tell somebody who hasn't attended, so they can decide to 
attend or not?


They are lots of fun and you'll meet interesting people.

Steve




___
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] Toronto on the Wiki...

[Steve Singer]

On Mon, 27 May 2013, Colin McGregor wrote:


I was looking at the Toronto, ON entry in the OSM wiki :
http://wiki.openstreetmap.org/wiki/Toronto .

Some of the material is out of date... Any thoughts as to how best to
fix things?


Just do it, it's a low edit volume wiki page if people don't like your edits 
the worst that will happen is a revert.


I've deleted the 'Progress' section since it don't see a lot of benefit in 
it.  The events section could be updated. Are there any good updated city 
wiki-pages that would be a good basis?


A lot of the wiki pages in Canada could use cleanup

Steve







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

Re: [Talk-ca] openstreetmap.ca

[Steve Singer]

On Mon, 25 Mar 2013, Fabian Rodriguez wrote:


If no one else has a better proposal, I'd like to offer the assistance
of FACIL (http://facil.qc.ca) in managing this. I welcome any other
members of this list to join me in this offer.



Another proposal is to let OSMF register the domain and have them point it 
at a server with whatever we want to do with it.  If OSMF owns the domain 
they could still point it at a community controlled server.


The nice thing about having OSMF host the domain over some other project 
like FACIL is that OSMF is focussed on openstreetmap and we don't have to 
worry about them losing interest in the project (or if they do the community 
has a much bigger re-hosting problem).


* I don't know what policies OSMF has (if any) for domains in cctlds. I am 
hope they would be willing to take over the domain if local community 
asks.


Steve



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

Re: [Talk-ca] Canada Post addresses that do not match municipality name

[Steve Singer]

On Tue, 23 Oct 2012, Andrew MacKinnon wrote:


OK I've figured it out.

Is a free source available for the boundaries of Old Toronto, North
York, York and East York as they existed before 1998? I have added the
boundaries of Scarborough and Etobicoke as boundary=administrative,
admin_level=10 which seems to make nominatim work propertly (though it
says that the addresses are in Scarborough, Toronto, Ontario, Canada
instead of Scarborough, Ontario, Canada which is not the correct
format).


The Toronto Open Data Catalogue apparently has the old bounaries listed
http://www1.toronto.ca/wps/portal/open_data/open_data_item_details?vgnextoid=31f0b940f1f49310VgnVCM103dd60f89RCRDvgnextchannel=6e886aa8cc819210VgnVCM1067d60f89RCRD

I recall someone determining the the 2.0 license was compatible with OSM.






___
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: [OSM-talk] [Imports] Import guidelines review

[Steve Singer]

On Wed, 6 Jun 2012, Worst Fixer wrote:


Hello.

Ich read current import guide lines. They are long. Hard to
understand. Easy to ignore. Even established mappers some times fail
following. Even when they want.
Look: http://wiki.openstreetmap.org/wiki/Import/Guidelines



Ich also want this easy guide lines to be enforced by DWG. I will help
finding people who ignore it.

Nobody should be able to import loads of data without any discussion
and escape a block and or revert.


Often we have situations like

1. Person emails @imports saying that they have really cool data and want to 
import it.
2. People reply with 'don't do it because of X', or ask 'how are you dealing 
with Y'

3. The person imports anyway.

This person discussed the import with the community but they still 
shouldn't have gone forward with it.  If we are updating the guidelines 
they need to be updated to address this.


Also a lot of imports fail on the uploading data step resulting in duplicate 
or unattached nodes. Guideline updates should also address this (maybe 
require importers to do a test import on dev and then revert the test 
import on dev)







--
WorstFixer, twitter: http://twitter.com/WorstFixer

___
Imports mailing list
impo...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/imports




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

[Talk-ca] PGCon - Ottawa

[Steve Singer]

If anyone is in Ottawa this coming week,  PGCON (www.pgcon.org) the 
annual PostgreSQL developers conference is taking place in Ottawa. 
PostgreSQL runs the main openstreetmap database and tends to be the source 
mapnik pulls data from for rendering instances.  A large number of the major 
postgresql developers are expected at the conference.  There is still time 
to register for the conference, it is lots of fun.


I will be giving a talk on using OpenStreetMap data, 'making your own 
maps'.  http://www.pgcon.org/2012/schedule/events/432.en.html


Steve



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

Re: [Talk-ca] Canadian imports: good or bad?

[Steve Singer]

On Wed, 25 Apr 2012, Paul Norman wrote:


2. There is not a consensus among the community that CanVec data can be
imported without verifying the data for internal consistency and where
possible against imagery.


If no one disagrees with the fact there is not a consensus that importing
CanVec without minimal verification is acceptable I'll go ahead and document
on the Wiki, using Andrew Allison's examples.


+1.

Is there enough support to use the positive rather than the negative 
language, ie 'There is consensus among the community that 
Canvec data should only be imported when the data 
elements have been verified for internal consistency/accuracy/existence with 
the available imagery'


Steve





___
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 imports: good or bad?

[Steve Singer]

On Sun, 15 Apr 2012, Andrew Allison wrote:



From what I see there are some conflicting arguments here.


I think the question posed in the subject 'good or bad' is the wrong one. Is 
there a way we can have our cake and eat it too? Can we get most of the 
benefits from all of your below arguments?


What conclusions can the Canadian community learn from our import experience 
during the past 3 years?.


We have tried 95% automated bulk imports (ie the road imports I did in 
Alberta and Ontario)


We have had mappers import an entire Canvec tile at once via JOSM

We have had mappers import a feature at a time in a single canvec (or 
and other sources) tile


I remain unconvinced that the regions in Canada that have had imports have 
had their local mapper communities harmed by these imports.  I don't see the 
regions (in Canada) that have had fewer imports or delayed imports having 
better local community development than places (in Canada) that have had 
extensive importing.


I also feel that not of all data sources are equal.  Even within Canvec some 
layers are excellent (ie roads and lakes in most of the country) while 
others are often so out of date it isn't worth the time to import (ie 
buildings in much of Southern Ontario)



When I was doing license replacement for roads I found it easier/faster to 
just trace over the GeoBase WMS layer(I don't consider that 'importing'). 
When I had to replace some lakes I found copy/pasting the features from the 
Canvec .OSM files produced a much better result (importing?).



Steve




1   Building a community of mappers to add features to the map. Ideally
local.

2   Canada is a huge country. I doubt that there are that many people
willing to commit to mapping every nook. I'm sure the amount of No
Trespassing signs itself would prevent it.

3   OSM is promoting itself as a competitor to google.

4   I would suspect most mappers are not aware of the license change
coming and the resulting impact.

Given the size of Canada, and the few mappers we have. I my self could
not and probably would not have never walked / driven on every road,
trail, river, lake forest etc without some else doing an import first
which I myself used a base to improve OSM.

I don't see any possible way to have a map without an import to use as
a base.

To counter my own points, Yes, you will find some people who see a
great white spot as a challenge. But looking at the changes made locally
I would think most people would rather tweak an existing road or park.

Andrew




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

Re: [Talk-ca] Re : Clean up progress and last push

[Steve Singer]

On Sat, 31 Mar 2012, Pierre Béland wrote:



Since I work more for developping tools, I am not as familliar as many of
you about re-mapping procedure.

I need clear ODBL Safe instructions on how to redraw areas like in Verdun
where large portions have to be redrawned. This morning, I was erasing
streets one by on  and redrawing them using nodes that cross other streets.
This way it is simple to redraw. But I now realize that this ways it keeps


In the JOSM license layer it shows each non-odbl clean node in red, (or 
oranage/yellow). I delete the way and any all non clean nodes for that 
way and remake it from the Geobase WMS layer.  I TRY not to join the way to 
nodes that are red from another intersecting way.  If the way I am working 
on crosses another non-odbl way I will either:


i) Delete that other way at the same time and remap them both
ii) Add new nodes on both sides of the intersection so if the intersection 
node is later deleted the shape of the way I am remapping doesn't really 
change.



I do not look at the tags of on the old way before I delete it.



nodes that are not ODBL. Is this means that I also have to remove nodes and
redraw them ?  Then this would mean erase first a complete sector and then
redraw it. This would be a more perillous aventure!

 
Pierre



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

Re: [Talk-ca] Automated imports of Canvec?

[Steve Singer]

On Thu, 15 Dec 2011, James Ewen wrote:


On Thu, Dec 15, 2011 at 9:05 PM, Steve Singer ssinger...@sympatico.ca wrote:


If someone were to import a 100% pure canvec data an empty openstreetmap
instance and render this as a background WMS layer would this then make
editing/importing canvec data in Potlach easier?  I think tracing a more
verbose version of canvec might be less error prone for many people than
importing direct from the .OSM files.


That would be nice to have. One of the difficulties with the Canvec
import is the fact that the Canvec data gave way in deference to
existing OSM data. This means that there are lots of places where we
need to connect the two together (not so hard), or where poorly
aligned ways were kept and better quality Canvec data was left out.

http://www.openstreetmap.org/?lat=53.786lon=-112.0373zoom=14layers=M


With respect to the automated GeoBase import I did a few years back (of 
which that is a sample of)  I can provide .osm files with all the excluded 
data to anyone that asks. At one point I had them up on a free filesharing 
site but I think that went away. I don't think Potlach can read these files 
though. If someone wants to setup a server that can server them up as WMS 
I'd be happy to provide the files as well.


I doubt people doing manual/semi manual canvec imports people any listings 
of what wasn't imported (I know I don't keep track of that).





Being able to see the Canvec data that was left out would be nice.
Being able to grab the segments that were left out and import them to
replace the poorly aligned ways copied from low resolution images
would be even better.

--
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

Re: [Talk-ca] Automated imports of Canvec?

[Steve Singer]

On Thu, 15 Dec 2011, James Ewen wrote:


on this issue... well onto the build that tool side. I'm probably one
of the problem children causing issues importing Canvec data because
I lack the knowledge of how to fix all the errors that are reported by
JOSM. I can't even find out where the errors are to fix them, so I
import and then go back with Potlatch because I know how to get that
program to work.


Does anyone have a URL for a WMS layer that displays Canvec roadnames for 
the smaller roads?  Everytime I've looked at the canvec WMS layers I've 
never seen names of non-highways show up.


If someone were to import a 100% pure canvec data an empty openstreetmap 
instance and render this as a background WMS layer would this then make 
editing/importing canvec data in Potlach easier?  I think tracing a more 
verbose version of canvec might be less error prone for many people than 
importing direct from the .OSM files.


Is there anyone on list with a server/bandwith to do this?

Steve



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

Re: [Talk-ca] data replacement north east mississauga

[Steve Singer]

On Sun, 11 Dec 2011, Richard Weait wrote:


On Sun, Dec 11, 2011 at 9:34 PM, Steve Singer ssinger...@sympatico.ca wrote:




The wiki will give some guidance on how to clean tainted objects.

http://wiki.openstreetmap.org/wiki/Open_Data_License/What_is_clean%3F

That page says
---
A node moved by a non-agreeing mapper is tainted.

Clean that node by moving it. 
---


That seems to say that if the JOSM license check tool shows a node as orange 
then to fix it I just need to move that node a small amount.  That doesn't 
sound right.  I would think that I would need to either move it back to the 
nodes original position (to where the node was before the first non-ct 
editor touched it) OR place the node somewhere based on on independent 
source (bing, canvec, my gps traces,...).  I don't see how whatever tools 
OSM will use to ensure that database is ODBL clean in April will be able to 
tell the difference between those and a casual adjusting of a nodes position 
in the course of editing.  Isn't deleting/replacing the node from an 
independent source the safe thing to do?


I would hate to spend time now 'fixing' now only to find out it three months 
that my fixes still left the data as  ODBL dirty.


Steve


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

Re: [Talk-ca] import complaints

[Steve Singer]

On Fri, 2 Dec 2011, Connors, Bernie (SNB) wrote:


Richard,

	Do you have a link to Import Guidelines that are specific to Canvec 
data?


I think http://wiki.openstreetmap.org/wiki/CanVec needs to have some 
specific guidelines for canvec imports.


In particular

1. A caution to avoid importing coastlines or large lakes unless you have 
substantial experience importing canvec and understand how coastlines get 
generated/rendered in OSM.  We have had enough problems/complaints with 
coastlines that I think we need a specific caution.


2. A warning to avoid duplicate features.  (one might argue that this is 
obvious but the generic import guidelines don't actually mention this and 
clearly people are importing a lot of duplicate features)


3.  To check keeprite (or something similar) after your import so you can 
find/fix some of the problems you will create.


If no one objects I will update the above mentioned wiki page to reflect 
include those warnings.


Steve





Bernie.
--
Bernie Connors, P.Eng
Service New Brunswick
(506) 444-2077
45°56'25.21N, 66°38'53.65W
www.snb.ca/geonb/


-Original Message-
From: Richard Weait [mailto:rich...@weait.com]
Sent: Friday, 2011-12-02 13:23
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] import complaints

dear all,

I've heard some LOUD complaints about imports in Canada.  Please be
sure to follow the import guidelines, including special import
accounts, and please be sure to check your work and fix errors.
Latest issue appears to be a large broken water polygon.

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

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

Re: [Talk-ca] Proposal: Removing imported aboriginal land

[Steve Singer]

On Thu, 27 Oct 2011, Paul Norman wrote:



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.


This is the only of your four points that I see as a good reason to delete 
data. Once we start deleting non-ct data it will need to be deleted or 
re-imported. If your going around and deleting data from non-ct acceptors I 
wouldn't let the public domain declaration stop you from deleting Sam's data 
at the same time.


We don't normally delete (imported or otherwise) with 
questionable tagging then we fix the tagging.  However I wouldn't want to 
see anyone importing more of these boundaries until the tagging issues are 
sorted out.




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.




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

Re: [Talk-ca] Lake Ontario Missing...

[Steve Singer]

On Sun, 28 Aug 2011, G. Michael Carter wrote:


Here it is.   http://www.openstreetmap.org/browse/relation/1206310
It's been bastardized beyond recognition.  I spent weeks on that.  oh well
guess lake ontario is considered a salt water ocean and nothing I say will
change that view.  


I also see that http://www.openstreetmap.org/user/fuego/edits  has been 
working on the lake on the past few days.  Sometimes too many people 
editting in an area at once without talking can create problems, but that 
probably still beats *nobody* editting in an area.


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

Re: [Talk-ca] Ping John Whelan?

[Steve Singer]

 In my edits I have included at least one bus stop from GTFS data, I
 don't have the rights to license it under CC-by-ODBL. At the time it
 was done my expectation was that this information would become
 available under CC-by-SA in the short term this has not happened.

 I have included information from a source that had other information on
 it. Not a major crime but it is technically a breach of copyright.

If you had just deleted a small handful of bus stops and other nodes with a 
comment deleting 4 bus stops, and 2 roads since the data was based on a source 
that turned out to not be OSM license compatible we wouldn't be have accepted 
that as a reasonable edit and thought little of it. Instead you deleted massive 
amounts of data, much of it that has no apparent licensing conflict with OSM.


 The two paragraphs above basically undermine any legal case that OSM
 would have concerning Ottawa data unless the data is removed when
 brought to your attention which is why I haven't specifically mentioned
 them before. Note it has now been brought to your attention and the
 responsibility for the integrity of the database is now yours if you
 choose not to accept the deletions. There are probably a few other
 instances in there somewhere.

You haven't yet told us which bus stops or change sets have copied data.   It 
is almost like me saying 'someone somewhere in the world has copied streetnames 
from google maps.  I'll just go and delete all the roads from OSM to be 
safe'.    Much of the data you deleted is clearly from Canvec and presents no 
licensing issues yet you deleted it.


 I have requested that my CT status be reverted. I have tried to
 request that my change sets / data be removed and I have manually
 deleted the suspect data which I think is all I can reasonably do. If
 you revert the deleting edits then you undermine the legal case for
 protecting the OSM database.

Life would be nice you could agree to termsconditions and then withdraw your 
agreement retroactively.  Just think, I could get a credit card agree to the 
two pages of  TC's and buy lots of cool stuff.   Then I could say to the 
credit card company 'I revoke the agreement, I'm not going to pay your all this 
stuff I bought because I can't afford your interest rates'.   


 There has been some discussion that I think you are aware of within OSM
 about imports. Basically the new CT is not import friendly. As a
 contributor you are responsible for the data you add to the project.
 This includes ensuring that only data that meets the licensing can be
 included. I don't think anyone can say what the license in future will
 be changed to or even if it will be changed. Essentially this means I
 cannot give an undertaking to CANVEC that OSM license will be
 compatible and acceptable in the future when I don't know what that
 license will be.

Both NRCan and the license working group have said that the CANVEC license is 
compatible with the OSM contributor terms.



 ___ 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] Ping John Whelan?

[Steve Singer]

1.  deleting the data for the reasons you've stated with the comment 
bicycle_rental bixi is anti-social and deceptive. At least put a comment in 
saying what your doing.

2. People should NOT be pre-maturely deleting their own non ct-terms data from 
the map.  Some day in the future OSM will delete the data from the map of 
people who did not accept the license.  Immediately before then OSM is supposed 
to release a final CCBYSA planet.osm dump.  Some people might want to take that 
planet file and use it as the basis for another project or map.  If you care 
about open-data then you should want that dump to be as complete as possible 
for the benefit of anyone planning on doing stuff with it.  By deleting your 
data now you remove that opportunity.    

4.  It is my understanding that NRCan has given OSM specific permission to 
incorporate the canvec data into OSM under the new CT terms.  If you decide 
that you don't want the data mapped from the GPS traces to be under the new CT 
terms then that is your right, but it is a bit unfair to say it is because your 
afraid of the CANVEC license terms.


Steve

-

Date: Mon, 6 Jun 2011 16:17:27 -0400
From: jwhelan0...@gmail.com
To: rich...@weait.com
CC: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Ping John Whelan?

Acting on your advice I accepted the new CT.  On looking more deeply into the 
subject I note that I have retrospectively allowed OSM to license anything I 
have ever added to the map in any way they wish.  Currently it is odbl but the 
CT allows anything, the license seems to be an ever changing document.


Looking at my data I have a couple of footpaths that were entered from a GPS 
track and one or two other items these I'm happy to have under the new CT but 
very little else.

I find it is not possible to retract my acceptance.


I have made three separate inquiries on how to get all my edits removed but all 
have been ignored.


So I can see no other option than to remove them all manually.  


If someone else wishes to do an import from CANVEC most can be replaced quite 
quickly, however I do not want to take the responsibility that OSM in its 
wisdom will change the license yet again to something that is not acceptable to 
CANVEC.


I also note that according to Fredrick some mappers have already been deleting 
entries for people who have not accepted the CT so it seemed to be an 
appropriate time to start deleting.

Sorry for any inconvenience.


Cheerio John

On 6 June 2011 15:28, Richard Weait rich...@weait.com wrote:

Dear John,



Your edit today http://www.openstreetmap.org/browse/changeset/8355694

deleted thousands of nodes and ways, with a comment of bixi

bike_rental but in fact deleted large portions of Leslie park.

http://www.openstreetmap.org/?minlon=-75.8392303minlat=45.3141652maxlon=-75.7587115maxlat=45.3763387box=yes




You seem to have accidentally made the same mistake yesterday, with

http://www.openstreetmap.org/browse/changeset/8355396 and several

other changesets which delete thousands of nodes and ways, removing

large portions of the map in Lincoln heights,  Bel-air hieghts,

Ottawa, etc.



What's going on, John?



http://www.openstreetmap.org/?minlon=-75.7155206minlat=45.3971371maxlon=-75.6772372maxlat=45.4266653box=yes


http://www.openstreetmap.org/?minlon=-75.7155206minlat=45.3971371maxlon=-75.6772372maxlat=45.4266653box=yes


http://www.openstreetmap.org/?minlon=-75.7847794minlat=45.338809maxlon=-75.705353maxlat=45.3970339box=yes


http://www.openstreetmap.org/?minlon=-75.8392303minlat=45.3141652maxlon=-75.7587115maxlat=45.3763387box=yes





___
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] Toronto Urban Mapping Party (June 11 2011)

[Steve Singer]

It has been a while since we've had a mapping party in Toronto focussed on 
mapping (versus talking about mapping).


On June 11'th 2011 we will have mapping party themed Urban Mapping.

Cities such as Toronto are filled with things much more interesting than 
roads. These things need to be on the map. The goal of this mapping party is 
to survey parts of downtown Toronto to create a better urban map.


Examples of things we are going to find include

* pubs and restaurants and stores
* public telephones and public toilets
* benches,water fountains and flower gardens
* newspaper boxes and garbage cans
* parking lots, bicycle racks and parking meters
* Are places wheelchair accessible

We will meet at noon at Camaraderie (http://camaraderie.ca/) 102 Adelaide 
Street East, 2nd floor, then head out mapping.


See  http://wiki.openstreetmap.org/wiki/Toronto/June_11_2011_mapping_party 
for more details.


Invite your friends, it will be fun.



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

Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada : Follow-up

[Steve Singer]

On Wed, 25 May 2011, Jean-Guilhem Cailton wrote:


Hi Pierre,

Any idea of sources for street names ?


The Canvec datafiles can be opened up in JOSM and can legally used as a 
source for streetnames in Quebec.


http://wiki.openstreetmap.org/wiki/Canvec
ftp://ftp2.cits.rncan.gc.ca/osm/pub/031/H/031H06.zip (I think this tile 
covers the area in question)



Steve

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

[Talk-ca] SOTM 2011 - Denver Call for Papers

[Steve Singer]

I hadn't noticed a posting to this list on SOTM 2011 in a while and was a 
bit surprised when I heard that the deadline for submitting talks is fast 
approaching.


SOTM is the big annual international gathering of OSM folks. This year it is 
being held in Denver in September.  Denver is easily accessible from most of 
the populated parts of Canada.


If your thinking of submitting a talk you have to submit a short proposal by 
March 15'th.  See http://stateofthemap.org/call-for-papers/ for details.



Steve



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

Re: [Talk-ca] How should a noob proceed?

[Steve Singer]

On Sun, 30 Jan 2011, Samuel Longiaru wrote:



then realized that doing so for each import would eventually lead to massive 
relations of
wooded area.  So would you agree that I should leave the bounding ways alone, 
only working on
merging or joining cross-boundary objects such as roads, railroads, etc., or 
should I treat the
bounding ways somehow ?


a) I would merge the nodes between on the objects so they are 'connected'.

For example, I think your nodes 1127393723 and 1127420928 probably should be 
merged.  If you zoom in with JOSM very close to those nodes you see that 
there is a gap between the north and south halves of the lake.


To merge a node in JOSM, zoom out enough so the mouse covers both nodes. 
Then left click to select a node, then use the centre mouse button(click 
it) Then hold down on CTRL and you  can now mouse over the other node (a 
popup should have appeared listing all the objects near the mouse) and 
select it with the left mouse button.  Both of the nodes should now be 
selected.  If your press M it should merge the two nodes.


Doing this might fix a lot of the issues your seeing with the validator.



For something like a small lake where the lake is going to span 4 tiles but 
the lake isn't that big I'd merge it.  But a wooded area that when merged 
takes spans 100km with hundreds of nodes should probably be split at some 
point.


(always merge nodes that represent the same point in space, but the 
associated ways don't need to be merged).





2) I am surprised in that the registry between the different objects in the 
CanVec data is not
better than it is... at least in this area.  For the most part, the boundary of 
the wood
(whether outer or inner) seems to be shifted westward in relation to the lake 
outlines which
are at least fairly consistent with the Bing imagery.  This internal shift 
within the CanVec
data seems to triggering a lot of errors... overlapping areas, crossing ways, 
etc.   The shift
seems to line up across both sheets.  Is this expected, and if so, should I 
just correct errors
as usual, using the Bing imagery as a guide?  Or is this error something that 
happened when
converting the data to OSM format?



I've seen this in other areas as well but I don't know what the cause of the 
shift is.


In many places the Bing imagery is better resolution and newer than what was 
used in Canvec.  If you think something from Canvec can be improved/fixed 
based on the Bing imagery then you should feel free to do so.  However 
sometimes the Bing imagery could also be  slightly mis-aligned (If you 
determine this you can realign the imagery in JOSM for your editing 
session).   If Canvec, Bing and your GPS traces all show something to be in 
the exact same spot then you can be confidient that the object is positioned 
right.  If all three sources show a slightly different position then it is 
hard to know which (if any) are correct.




Sam

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

Re: [Talk-ca] How should a noob proceed?

[Steve Singer]

On Sat, 29 Jan 2011, Samuel Longiaru wrote:


Greetings Everyone,




My immediate problem is that I am not familiar enough with the tools or the 
process for even
checking out the quality of the Canvec data in this area.  I suspect it is 
better than what is
here now.  So either if someone were willing to import a block from an area 
nearby, or be
willing to act as a mentor and guide me off list through the process, then 
perhaps I could
proceed a bit more effectively.  I've tried to research the process myself, but 
hate to screw
something up if you know what I mean.


I wrote up a post a while back describing how I was doing Canvec importing 
with JOSM. http://scanningpages.wordpress.com/2010/08/08/openstreetmap-canvec-importing
Might be a good starting point.  Feel free to ask if something I describe 
there is unclear.








Thanks for any input and/or assistance.

And sorry... yes, another Sam on the list.

Sam Longiaru
Kamloops, BC





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

Re: [Talk-ca] Street name upload

[Steve Singer]

On Wed, 26 Jan 2011, Bégin, Daniel wrote:



Salut osmers,

Is there an easy way (an application of some kind) that can be used to transfer 
street name
from Canvec street network/Karlsruhe schema to name tag on existing road 
network. 

This release of Canvec.osm in Quebec area has addressing/street name, but 
manual transfer of street name on existing road network takes up to 95% of 
uploading time.


This might be a good use of RoadMatcher.

-Use RoadMatcher to match existing roads in osm with the canvec.osm tiles 
with the names to produce a mapping of exisitng osm_id values to the id 
values in the canvec.osm file


-Write a script that takes each unamed road and grabs the way from the API 
adds the matched name from canvec.osm and uploads the new version of the 
way.










Any ideas?

Daniel




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

Re: [Talk-ca] [OpenStreetMap] GeoBase Aboriginal Lands Import 2010

[Steve Singer]

On Sun, 12 Dec 2010, Sam Vekemans wrote:


I'm just cc'ing talk-ca.


and im not sure about the renderings/tagging of this.
... perhaps it's better if i remove everything that i added?


I don't see why you should remove this data just because we don't have an 
approved way to tag it. If anything the tagging should 
be changed.  'boundary=aboriginal_lands' still seems to be a proposed 
rather than accepted tagging. I suspect his complaint with admin_level not 
being an integer, which I see as a fair tagging complaint but I would be 
inclined to try get some sort of tagging consensus (at least for the 
americas+austrilia) before changing the tag to another unapproved values.



Also, I'm not a big fan of 'cc:'ing someones private message through the OSM 
mail system to a public mailing list.


Steve



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

Re: [Talk-ca] OSM Import Validations

[Steve Singer]

On Thu, 28 Oct 2010, Pierre Beland wrote:



I wonder if potential intersection errors coming from NRNGeobaseV5.0 or 
Canvec V6 Imports have been unnoticed and if some correction should be 
made to the Canvec import script (culvert or layer=-1 ?).


So how should things like The riverbank intersects the highway be tagged?
or are they false positives from the validators?

If a stream passes through a road; it probably shouldn't share a node with 
the node because they don't form an intersection and they don't really share 
a geometry.


There is nothing on the wiki for the waterway=river or layer tags that tells 
me I should be using 'layer=-1' (or anything else for that matter).


Steve





Pierre Beland




http://keepright.ipax.at/report_map.php?lang=frch30=1ch40=1ch50=1ch60=1ch70=1ch90=1ch100=1ch110=1ch120=1ch130=1ch150=1ch160=1ch170=1ch180=1ch191=1ch192=1ch193=1ch194=1ch195=1ch196=1ch197=1ch198=1ch201=1ch202=1ch203=1ch204=1ch205=1ch206=1ch207=1ch208=1ch210=1ch220=1ch231=1ch232=1ch270=1ch281=1ch282=1ch283=1ch284=1ch291=1ch292=1ch293=1ch311=1ch312=1ch350=1number_of_tristate_checkboxes=6highlight_error_id=0highlight_schema=0lat=51.02657lon=-114.03854zoom=14show_ign=1show_tmpign=1layers=B00Tch=0%2C30%2C40%2C50%2C60%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C282%2C283%2C284%2C291%2C292%2C293%2C311%2C312%2C350

http://keepright.ipax.at/report_map.php?lang=ench30=1ch40=1ch50=1ch60=1ch70=1ch90=1ch100=1ch110=1ch120=1ch130=1ch150=1ch160=1ch170=1ch180=1ch191=1ch192=1ch193=1ch194=1ch195=1ch196=1ch197=1ch198=1ch201=1ch202=1ch203=1ch204=1ch205=1ch206=1ch207=1ch208=1ch210=1ch220=1ch231=1ch232=1ch270=1ch281=1ch282=1ch283=1ch284=1ch291=1ch292=1ch293=1ch311=1ch312=1ch350=1number_of_tristate_checkboxes=6highlight_error_id=0highlight_schema=0lat=49.96809lon=-98.26698zoom=13show_ign=1show_tmpign=1layers=B00Tch=0%2C30%2C40%2C50%2C60%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C282%2C283%2C284%2C291%2C292%2C293%2C311%2C312%2C350

http://keepright.ipax.at/report_map.php?lang=ench30=1ch40=1ch50=1ch60=1ch70=1ch90=1ch100=1ch110=1ch120=1ch130=1ch150=1ch160=1ch170=1ch180=1ch191=1ch192=1ch193=1ch194=1ch195=1ch196=1ch197=1ch198=1ch201=1ch202=1ch203=1ch204=1ch205=1ch206=1ch207=1ch208=1ch210=1ch220=1ch231=1ch232=1ch270=1ch281=1ch282=1ch283=1ch284=1ch291=1ch292=1ch293=1ch311=1ch312=1ch350=1number_of_tristate_checkboxes=6highlight_error_id=0highlight_schema=0lat=43.12901lon=-81.96309zoom=12show_ign=1show_tmpign=1layers=B00Tch=0%2C30%2C40%2C50%2C60%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C282%2C283%2C284%2C291%2C292%2C293%2C311%2C312%2C350

http://keepright.ipax.at/report_map.php?lang=ench30=1ch40=1ch50=1ch60=1ch70=1ch90=1ch100=1ch110=1ch120=1ch130=1ch150=1ch160=1ch170=1ch180=1ch191=1ch192=1ch193=1ch194=1ch195=1ch196=1ch197=1ch198=1ch201=1ch202=1ch203=1ch204=1ch205=1ch206=1ch207=1ch208=1ch210=1ch220=1ch231=1ch232=1ch270=1ch281=1ch282=1ch283=1ch284=1ch291=1ch292=1ch293=1ch311=1ch312=1ch350=1number_of_tristate_checkboxes=6highlight_error_id=0highlight_schema=0lat=45.32363lon=-72.3307zoom=13show_ign=1show_tmpign=1layers=B00Tch=0%2C30%2C40%2C50%2C60%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C282%2C283%2C284%2C291%2C292%2C293%2C311%2C312%2C350


http://keepright.ipax.at/report_map.php?lang=ench30=1ch40=1ch50=1ch60=1ch70=1ch90=1ch100=1ch110=1ch120=1ch130=1ch150=1ch160=1ch170=1ch180=1ch191=1ch192=1ch193=1ch194=1ch195=1ch196=1ch197=1ch198=1ch201=1ch202=1ch203=1ch204=1ch205=1ch206=1ch207=1ch208=1ch210=1ch220=1ch231=1ch232=1ch270=1ch281=1ch282=1ch283=1ch284=1ch291=1ch292=1ch293=1ch311=1ch312=1ch350=1number_of_tristate_checkboxes=6highlight_error_id=0highlight_schema=0lat=45.81536lon=-71.1483zoom=11show_ign=1show_tmpign=1layers=B00Tch=0%2C30%2C40%2C50%2C60%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C282%2C283%2C284%2C291%2C292%2C293%2C311%2C312%2C350

Re: [Talk-ca] Fwd: GeoBase vs CanVec

[Steve Singer]

On Mon, 23 Aug 2010, john whelan wrote:


The CANVEC tiles contain the full street name.  Ottawa has a number of
streets that were imported from Geobase that did not include a street
name, contained abbreviation or only part of the name.

This maybe because of the way the import was done but the CANVEC data
seemed cleaner in this regard.



The Ontario road network imported into OSM came from version 5 of the 
GeoBase release (that was the newest version of the time).  v5 of the 
Ontario geobase road network had no road names in Ontario.  When I did the 
import I took the road names from the StatsCan data and matched them to the 
Geobase road geometries.


The Canvec files Daniel is now producing I think include data from the v6 
Geobase road network.  These do include road names (and presumably have 
other updates).


Someone could probably write a script to go through the v6 geobase data and 
update the matching OSM roads with the more up-to-date names and better 
geometries, but I'm leaving that as an exercise to the reader.


Steve





Cheerio John

On 23 August 2010 09:14, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote:

Hi Brendan,

John described the difference between Canvec and GeoBase pretty well!

Daniel

From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of JOHN SMART
Sent: 20 août 2010 20:46
To: Brendan Morley; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Fwd: GeoBase vs CanVec

G'Day Australian Mapper

Perhaps someone from Natural Resources Canada (the Federal mapping agency)
could give a better answer, but my understanding is:

- CanVec originated from the NTDB (National Topographic Database) which is
essentially the same data as is used for the (sometimes quite out of date)
1:50 000 scale National Topographic Series maps. That is all Federal data.

- GeoBase is an initiative which aims to reduce duplication of work / costs
by having Provinces (equivalent to Aus. states) or other entities supply
best data to the Feds.

Thus GeoBase would actually be an example of the left hand working in
partnership with the right hand.

I believe CanVec is being updated with any better sources as they become
available, e.g. National Roads Network (NRN) gets migrated into new editions
of CanVec.

I believe there are many data themes that are in CanVec which are not in
GeoBase, and presumably never will be in GeoBase unless the initiative is
extended to include agreements for those themes.

If I have misunderstood anything I'd be delighted to be corrected.

Now, what is CommonMap? I had never heard of that until now. A quick web
search gets me here:
http://commonmap.info/w/index.php/Main_Page

It looks to me like it is a very similar concept to OSM, apart from
licensing perhaps. So it makes me wonder if we have a left hand - right
hand situation there?

John



From: Brendan Morley morb@beagle.com.au
To: talk-ca@openstreetmap.org
Sent: Fri, August 20, 2010 9:11:10 PM
Subject: Re: [Talk-ca] Fwd: GeoBase vs CanVec

Also, I assume if I were to import GeoBase data into CommonMap, I should
follow closely the rules implemented in
http://svn.openstreetmap.org/applications/utils/import/geobase2osm/geobase2osm.py
?


Brendan

On 21/08/2010 9:52 AM, Brendan Morley wrote:

Hello Canadian mappers,

Sam Vekemans suggested I ask the following here:

What is the relationship between CanVec data and GeoBase data?

To this layperson they seem to be two initiatives hosted by the same
government that seem to have similar objectives.  Almost like the left hand
not talking to the right hand.

Can anyone explain briefly the differences?  For example, it seems to me
that GeoBase is closer to the data authors, and CanVec feeds from that,
and CanVec concentrates on having complete coverage at particular scales
(like 1:50k).
Am I on the right track?
Is there a government document that goes into detail?

My interest is to pick out the best bits to seed CommonMap with.  I'm
looking for accuracy and timeliness.


Brendan

___
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 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] Merging CanVec data, updating status

[Steve Singer]

 
 I was wondering is there anyone else editing in Ontario.  If everyone 
 keeps putting the CanVec tile code they processed in the comments 
 section of the changeset, I don't mind updating this spreadsheet.  Just 
 need to know who's working on CanVec tiles.

I'm hoping to give at the 031E6 tiles a shot.

When I try to look at that tab in the spreadsheet  I get the current window is 
too small... and I'm unable to get it to scroll 
the screen past the first few rows.

 
 Michael
 
 
 ___
 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] Modifying GeoBase Ways.

[Steve Singer]

On Tue, 17 Nov 2009, James Ewen wrote:

 We as the OSM community have chosen to accept the restrictions in
 order to be able to import HUGE amounts of data, but it leaves us with
 a quandary... how much modification of the imported data needs to
 happen BEFORE the attribution can be REMOVED?

When we started importing the geobase data we took the safe approach and 
attribute each way.  The idea being that with all that attribution no one 
could argue that we are not complying with the geobase terms.  However I 
can't recall if anyone has said that this level of attribution is actually 
required by the geobase license.

Maybe someone with better license reading skills than myself or Sam can 
figure out what the minimum level of attribution is actually required.

From a license point of view:

Is putting the attribution in the changeset tags sufficient to comply with 
the license?

Is putting the attribution on the wiki data sources page sufficient to 
comply with the license?




 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

Re: [Talk-ca] Correcting Geobase_import_2009

[Steve Singer]

On Sun, 25 Oct 2009, john whelan wrote:

 What appears to have happened is where the data has been merged roads
 that are in the geobase database no longer connect to roads that have
 been put in via potlatch.  I think the end point is dropped.  The
 older potlatch roads do not have the same depth of tags as the geobase
 data.  Not only that but roads that run close to the old roads appear
 to be deleted for the section close to the potlatch inputted roads.
 Oh and my WAAS enabled GPS thinks at least one Potlatch inputted road
 is in the wrong place.

Yes, in places where a road already existed in OSM the software we used to 
avoid duplicating the road with the geobase version sometimes results in 
missing the connecting segment or other segments of the geobase road close 
to an existing OSM road. If you see places like this it is best to just fix 
things up.

Steve


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

Re: [Talk-ca] Setting up RoadMatcher and creating shapefiles

[Steve Singer]

On Fri, 25 Sep 2009, Sam Dyck wrote:


Can you give me an idea as to which parts/steps of the instructions at
http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature your having 
problems with? I'm can try to clarify/provide more info on any steps that 
are unclear.

Basically you need to

1. Load the NRN data into postgis (using shp2pgsql which is included with 
postgis)
2. Load the OSM data into postgis with osm2pgsql
3. Generate shapefiles with the NRN and OSM data using stored procedures 
similar to those posted on the wiki page

Then you need to import the files into OpenJump/road matcher (The wiki has 
some instructions on doing this, and I can try to answer if anything isn't 
that clear).

Steve

 Hi

 Sorry to ask for help, but I really want to start importing Geobase data for
 Manitoba and Saskatchewan. If someone is able to help me install RoadMatcher
 on (open)JUMP and create Shapefiles from OSM data on a Debian GNU/Linux
 system. Again, if it is such an odious task forget it. But to the best of
 knowledge there is no one importing data for these provinces, and it would
 allow me to focus on other features of the map if this data was imported.
 Thanks

 Sam D.



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

Re: [Talk-ca] Canada Data Import Status was edited recently

[Steve Singer]

On Sat, 19 Sep 2009, Frank Steggink wrote:

 Sorry, I meant statscan. I'm not sure how to add the data. The wiki page
 mentions Download in shapefile format and use OpenJump to add road
 names from Statscan, but I don't know how to accomplish that. Regarding
 roads traced from Yahoo and other imagery: they're generally more
 accurate than the Geobase data, so I'm not sure if that would be a good
 idea.

What I do with the statscan data is

1. Load the larger (ie province wide )shapefile into postgis with shp2psql
2. Generate a smaller shape file with something similar to the stored 
procedure listed ont he wiki page 
(http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature#Road_Names_from_StatsCan)
3. Run RoadMatcher on the smaller GeoBase shapefile and the StatsCan 
shapefile
4. I then pass the road matcher result to geobase2osm with the -n option.

If you need more details/help with any of these steps let me know where the 
gaps are and I can try to expand.



 OK, so uploading the complete out.osm file is enough. I still have the
 standalone and excluded files, and tried to keep them in sync with the
 changes I made (after the initial upload and corrections), but I can't
 guarantee they're still right. I wonder if, once new Geobase data is
 available, it wouldn't be better to download the data from OSM. There is
 a chance that new additions have already been surveyed and added to OSM.

I feel the complete files are useful becaues it gives someone the geobase 
view of things.  I find the excluded files are only useful to point out 
areas where geobase might have missed roads or pointing out areas that 
likely need some manual attention.  If your giving manual attention to areas 
before you uplaod to OSM then having the excluded files might not be that 
valuable to someone else.



 Frank


 ___
 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] Logged Canadian Road Trip

[Steve Singer]

On Fri, 28 Aug 2009, Tim Francois wrote:


Tim,

My understanding is that many of the major highways in your trip were mapped 
from aerial imagery, so a 1 point per second gps trace is probably more 
accurate.   Uploading your gpx tracks to OSM so others can see them as a 
datasource for tracing/ would be good.  If based on your traces/having been 
there that you feel any roads should be adjusted in OSM that you should feel 
free to do so as well (respecting standard OSM  map editting etiquette 
etc...)


There is a larger project to import roads from a government database 
(Geobase) but right now we don't have any automated techniques for improving 
existing roads (just adding new ones), sometimes a good GPS trace is better 
than this data anyway.


 Hi all,

 I live in the UK, but parents live in Calgary. This summer we went on a
 somewhat extended roadtrip, taking in Alberta, BC, Yukon and Alaska. I
 had my netbook and GPS mouse with me and logged pretty much the entire
 trip, checking the OSM map accuracy using Navit (on Linux). Some major
 roads we traveled include:

 - Trans-Canada from Calgary to Vancouver
 - Highway 4(a) on Vancouver Island from Parksville (Nanaimo) to
 Tofino/Ucluelet
 - Highway 19 Parksville to Port Hardy (including little bit around
 Telegraph Cove)
 - Highway 16 from Prince Rupert to Highway 37 (Cassiar Highway) intersection
 - Cassiar Highway (37) from Highway 16 up to Alaska Highway intersection
 (including road to Stewart, BC and Hyder, AK)
 - Almost entire Alaska Highway from Tok, AK to mile 0 in Dawson Creek
 - All Highways on the Klondike loop, including:
 -- Highway 2 (Klondike Highway) from Dawson City to Alaska Highway
 -- Highway 11 (Silver Trail) from Stewart Crossing to Keno
 -- Highway 9 (Top of the World Highway) from Dawson City to USA border
 -- Relevant highways in Alaska, though that's not for this mailing list
 - Dempster Highway from mile 0 into NWT
 - Highway sections from Dawson Creek to Calgary (via Highway 22)

 So I have GPX files for almost the entire trip, with a point logged
 every second. My questions:
 1) All of the highways are on OSM in one form or another, but I'm
 assuming most were not added via GPX points. When following on Navit the
 mapped road sometimes varied substantially from the actual road. Is this
 a correct assumption?
 2) If 1) is correct, is it then OK to improve all these highways with
 the GPX tracks?
 3) Is someone else already doing this, or is there a larger project
 ongoing under which this should be maintained?

 Any info/input is gratefully received - I don't want to start updating
 things and then realise I'm treading on someone else's toes!!

 Thanks
 Tim

 ___
 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] Problem with big file in JOSM

[Steve Singer]

Yan Morin wrote:
 shp-to-osm don't split relations and I can't import with the bulk upload 
 script because these two files are two big for OSM 0.6 API limits.


Which limit is it too big for?

Bulk_import.py should take a large changeset and split it into smaller 
upload chunks that fit inside the API limits.

However if you have a way with more than 2000 nodes or are violating the 
other hard API data limits then bulk_import.py or JOSM won't help you. 
You will need to split your way into multiple smaller ones and then 
connect them with a relation.

Steve

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

Re: [Talk-ca] Catch up

[Steve Singer]

Jim Shaver wrote:
 I just joined OSM today.  Was so excited I jumped in the car immediately 
 and started making traces and uploading them.  I was also excited to see 
 that OSM is working on an import of the GeoBase information.  Can 
 someone point me in the right direction as to where I can catch up on 
 what is involved in this process?  What formats are coming out of 
 GeoBase?  I have some programming experience and would love to help out 
 on that end if needed.  I live in Saskatchewan, but have lived in 
 Alberta and BC as well.
 
See

http://wiki.openstreetmap.org/wiki/GeoBase
http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature
http://wiki.openstreetmap.org/wiki/CanVec_OSM_Map_Features

For more details

GeoBase gives out the data in Shapefile and GML format.   We have a 
program that converts the roads from the GML to osm format for upload. 
We also have some techniques for trying to avoid importing roads already 
in OSM.

Read over the wiki pages and feel free to ask specific questions if 
anything is unclear.  I don't think anyone has yet started on roads in 
Saskatchewan.


Steve




 Jim
 ===
 http://jshaver.com
 
 
 
 
 ___
 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] Fixing GeoBase unconnected ways/nodes.

[Steve Singer]

On Wed, 22 Jul 2009 si...@mungewell.org wrote:

As Sam mentioned, you can get the complete OSM files at 
http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature#Status

You can lookup the NTS tile number for the area your interested in at 
http://atlas.nrcan.gc.ca/site/english/maps/topo/map

Also the Alberta files are the ones from the original import, many of them 
suffer from the unconnected/duplicate node problems that plagued the parts 
of the Alberta import.  If you email me the areas that your going to work in 
I can probably regenerate the complete .osm file to not have that issue (but 
I might not have time to get to it right away)




 In the south of Duncan area, the local are mapper has been helping me out,
 by after i dropped in the GeoBase roads (from the file that Austin made,
 but
 didn't use roadmatcher)

 Can I get a download link for this 'GeoBase' OSM file? There are some
 roads in Alberta where the original OSM way was poor quality/location,
 which has resulted in the GeoBase import just dumping fragments all over
 the place.

 A 'good' (meaning 'bad') example would be Highway 5 west of Cardston.
 http://www.openstreetmap.org/?lat=49.184lon=-113.581zoom=11layers=0B00FTF

 I think the best way to fix this would be to delete the original OSM way
 and overlay a 'new' GeoBase road in it's place.

 I would also be 'nice' to be able to cherry pick information (such as road
 names) where they exist in GeoBase but not in OSM.


 Anyway, great job (i wish i could understand how to use it :)

 I can 'talk' you through it on IRC/VoIP if you want. Drop me a note off list.

 Simon.



 ___
 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: [OSM-talk] upload error using bulk_upload.py

[Steve Singer]

On Wed, 1 Jul 2009, maning sambale wrote:

 Hi,

 I get this error using bulk_upload.py:

 $ python bulk_upload.py --input=pas_osm.osm --user=
 --password= --comment=*
 bulk_upload.py:42: DeprecationWarning: the sets module is deprecated
  import sets
 Uploading change set:1701375
 Error uploading changeset:404


A 404 is Not Found

What is in the file your trying to upload, is it a set of node adds, deletes 
or modifications?

Is it possible that your trying to delete/modify an item that has already 
been deleted?

Steve




 Any advice?
 -- 
 cheers,
 maning
 --
 Freedom is still the most radical idea of all -N.Branden
 wiki: http://esambale.wikispaces.com/
 blog: http://epsg4253.wordpress.com/
 --

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



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

Re: [OSM-talk] upload error using bulk_upload.py

[Steve Singer]

On Thu, 2 Jul 2009, maning sambale wrote:

 Hi,

 These are all new nodes and ways (protected area boundaries) converted
 from a shapefile using polyshp2osm.py.
 I did manual modifications using josm but since josm has limits for
 each changeset, I tried th bulk_upload script.

 Another weird thing is:

  node id='-4' action='modify' visible='true' version='0'
 lat='11.1185' lon='119.196' /

I think the problem is that it has action=modify.
Node id=-4 isn't a real node id so that node isn't yet in OSM. 
bulk_upload.py sees the action=modify and takes that to mean that it 
should upload the node as a modification, when it really needs to upload the 
node as an add.

If you strip out the action=modify I think it will work.

I'm not sure if bulk_upload.py is doing the correct thing on a 'modify' with 
a negative node number or if the node id should take precedence over the 
action.



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

Re: [Talk-ca] geobase2osm.py work / questions

[Steve Singer]

On Tue, 30 Jun 2009, William Lachance wrote:


 1. Intersection at spruce grove of two highways with dual carraigeways:

 http://www.openstreetmap.org/?lat=53.5578961lon=-113.9100716zoom=14layers=B000FTF

 8 duplicated nodes here.

Are you seeing 8 duplicate nodes on the live OSM map? If so what are the 
node id's.  When I'm not sure which intersection your refering to. For 
example http://www.openstreetmap.org/browse/way/31681540 is sharing nodes 
with some of the connecting ways.  (note that some of the ways in this area 
are non geobase ways that don't yet connect to the geobase ones)

 I've uploaded a full list of duplicated nodes for the Edmonton area,
 if anyone wants to see more evidence. :) It's just a raw list of
 lat/lng coordinates, prefixed with the number of duplicated nodes that
 geobase2osm is generating at that position. Check it out at:

 http://wlach.masalalabs.ca/edmonton-dupe-nodes

For example the last one on the list

8 53.5578961, -113.9100716

When I search my  version 5 Alberta NRN file I see 3 Geobase ways that have 
a node at that location

ba63f7ea50484da990858e0af964d867
f6b43dd752e24cceb7eeebad5059888f
0e3f0a6ddc2b4a6e8d5d754639570516

When I generate a clean .osm file with geobase2osm for the 083GH tiles each 
of these ways shares a common node.  What is the exact bounds file your 
using in your test, perhaps there is a bug that only shows up with certain 
inclusions/exclusions?  Keep in mind that the .complete and file uploaded 
from the original import was done with the version of geobase2osm that had 
the merging bugs (but the data uploaded in OSM has since been fixed(as far 
as I know ))


In Alberta
fa0eaa9c6edd4f08aef6cc27e9f91ba4 and cf5c268bc5d4464cb485fc6d2aa71324 with 
node (53.5411265,-113.3799206) is an example of a place where two streets 
have a node at the same location but are not intersections according to the 
geobase data. I think this an overpass so the where you can't really route 
from one to the other.

b777800e3e4747dfbf2a417259e3c176 at (53.5805167,-113.4528248) with 
6e24a4f112894569a18387fbc0777b3f is another. The ramp for the highway must 
be going over the highway not joining it at the common node.





 Do we have consensus that it would be better to use my approach? If
 so, how do we go about updating the official script?

I think we need to use the junction data include with geobase to decide when 
to join nodes.  It that the code isn't working right then we should fix it, 
but I don't think we want to join all nodes that share  the same point in 
space.


Steve



 -- 
 William Lachance
 wrl...@gmail.com



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

Re: [Talk-ca] geobase2osm.py work / questions

[Steve Singer]

On Fri, 26 Jun 2009, William Lachance wrote:

 Hi all,

 I've been needing to use geobase2osm in a project of mine (not
 directly related to the geobase import), and noticed (as other people
 have) that it's generating a lot of duplicated nodes. Aside from being
 unclean and wasteful, this makes the generated osm file non-routable.
 Well, today I decided to do something about it. Looking at the source,
 I noticed quite a bit of complicated code to merge identical OSM
 nodes at junctions (trusting geobase to provide the right hints of
 where junctions are). Evidently this wasn't working quite as expected.



 I decided to try something simpler: just keep a hashtable of node
 keys (latitude and longitude) as you go along, and reuse nodes that
 have occurred before. :) At first glance, this approach seems to work
 fairly well. It seems intuitively right to me that if two ways have
 a common lat/lng point in common, they should be connected. A quick
 count of running the two algorithms on Edmonton, Alberta, reveals that
 where the old script resulted in 77242 (!) overlapping nodes
 (sometimes up to 8 on a single lat/lng position!), my code resulted in
 0.

Is this because the geobase data doesn't define Junction objects for those 
positions or some other reasons? Can you post a few examples of these?
I wasn't aware that recent versions of the script were still doing this. (I 
probably won't get to look into the details for a few days though)


If the junction data turns out to be incomplete then maybe we are better 
merging all common lat/lon pairs.



 Incidentally, this technique (if it's a good one) could be applied in
 automatic fashion on existing portions of the geobase import,
 eliminating the need for tedious manual work.

What does your hash do to the memory usage for the script. On the systems I 
run it on RAM tends to be a more limiting factor over other things.



 Anyway, I don't have commit access to the OpenStreetMap subversion
 repository holding geobase2osm, so I decided to fork the repository
 using git and put up the result here:

 http://github.com/wlach/geobase2osm

 Oh, I also patched it up to not do coordinate transforms between the
 NAD83 and WGS84 systems, as apparently
 (http://sci.tech-archive.net/Archive/sci.geo.satellite-nav/2006-09/msg00307.html)
 there is no difference when it comes to positioning. Empirically, this
 seems to be true: the output without this transform seems 100% fine.
 Dropping these transforms allows us to drop the osgeo dependancy,
 which makes the whole thing run on OpenSUSE in the first place.


According to that link the there is a 1.5m offset between the two coordinate 
systems.  That doesn't seem insignificant, maybe someone with a stronger GIS 
background can comment further on how important the correction is.




 More exciting geobase2osm work coming later. Maybe.

 Questions/comments? Let me know!

 -- 
 William Lachance
 wrl...@gmail.com

 ___
 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] Ontario NRN import update

[Steve Singer]

On Wed, 24 Jun 2009, Jeff McKenna wrote:

 Hi Steve,

 I now live in Nova Scotia, I'm a geomatics guy, I'd love to help with
 this NRN-NS import, but I'm a rookie as the OSM thing (but I want to
 learn!).  Are you going to yield to a hardened OSM veteran, or is there
 room for a rookie like me to help?  Let me know.

Read over http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature 
and let us know what parts are unclear.

A few others have been working on improving the instructions, so they are 
getting into a followable state.

I'll leave Nova Scotia to you and William, I'll work on a province that no 
one is working on.




 -jeff



 -- 
 Jeff McKenna
 Director, Gateway Geomatics
 http://www.gatewaygeomatics.com/




 Steve Singer wrote:
 I NRN roads covering all of Ontario have now been imported.  It is possible
 that I missed a few areas (if so let me know). I will soon run a script
 connect intersections in adjacent tiles. The wiki has links to  .osm files
 containing the excluded and complete roads are available at links on the
 wiki.

 I'm thinking about doing Nova Scotia or Newfoundland next.  If anyone local
 wanted to do either of these let me know and I'll yield to you.

 Steve




 ___
 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] Ontario NRN import update

[Steve Singer]

I NRN roads covering all of Ontario have now been imported.  It is possible 
that I missed a few areas (if so let me know). I will soon run a script 
connect intersections in adjacent tiles. The wiki has links to  .osm files 
containing the excluded and complete roads are available at links on the 
wiki.

I'm thinking about doing Nova Scotia or Newfoundland next.  If anyone local 
wanted to do either of these let me know and I'll yield to you.

Steve



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

Re: [Talk-ca] Roadmatcher - NRN for PEI

[Steve Singer]

On Mon, 15 Jun 2009, Robert Shand wrote:

Where did you get your RoadMatcher from?

The version 
http://sourceforge.net/project/showfiles.php?group_id=118054package_id=320958 
(that the wiki page seems to link to) should work with OJ 1.3

If you've used the version of RoadMatcher from the main roadmatcher site you 
should just be able to replace the .jar file with the binary I'm using
http://www.easy-share.com/1905578997/roadmatcher-1.4.jar

If your still having problems try posting the text and the error your 
getting and I might be able to come up with some more ideas.

Steve


 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi everyone,

 I've spent some time looking at importing the NRN for PEI.  I've
 successfully managed to get to the stage where I've got a NRN.shp and
 a OSM.shp. The next task is to run the Road matcher.

 I'm on a Mac (10.5.7). I've downloaded Open Jump 1.3 and
 Roadmatcher1.4forOJ

 However when I copy the Roadmatcher directory into the OpenJump/lib/
 ext directory it doesn't seem like Open Jump is loading the plugin. I
 noticed that the OJ is on 1.3 and RM on 1.4 is that a problem?

 Does anyone else have any suggestions for getting this next step done.

 Thanks

 Bob

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.8 (Darwin)

 iEYEARECAAYFAko29/UACgkQ2Nq71QUgsRHLuwCfQ+QHbYpOGjVBt9Otz7Tlbr1K
 f9UAn25RgY519UPjA7l+mjA6a46QLJ+C
 =qIvE
 -END PGP SIGNATURE-

 ___
 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] Ontario 040P

[Steve Singer]

On Sat, 13 Jun 2009, Adam Glauser wrote:

 I've found a way[1], which appears to have come in with this import,
 but is incorrectly named.  I checked out the Geobase website and found
 their viewing tool[2], but I can't see the names for the NRN ways.
 How can I check whether this is, in fact, an error in the NRN data?

 Secondly, when I fix it, how should I be changing the import-related
 tags (such as attribution, source, and geobase:*)?

The RoadNames in Ontario don't come from GeoBase, they come from the 
StatsCan data set.  I run roadmatcher on the GeoBase and StatsCan data to 
try and assign names to GeoBase geometries.  The statscan data is known to 
have positional issues.

The only way you can check this is to look at both the StatsCan data and the 
GeoBase data together (using something like openjump)

http://wiki.openstreetmap.org/images/3/32/Brookmill.jpg

The blue lines are GeoBase roads.

The green lines are StatsCan roads with the name.

The (yellow selected) line is the way in question (geobase 
uuid:3bca7e20d3664bc48b79c47c441b1175).  RoadMatcher matched that with 
Brookmill Crescent.  I can sort of see how roadmatcher got confused.  I 
was expecting name mismatches to sometimes happen (because the 
statscan/geobase data at times differs by a lot).  So far this is the first 
report of a mismatched name in Ontario, if the problem is widespread I can 
try adjusting the roadmatcher settings (which would mean fewer matches thus 
fewer roads with names).

To fix it I would recommened deleting the statscan:rbuid = 3357609 tag and 
fixing the name.


As a side note: Doing this type of analysis would be much harder without 
having the statscan and geobase id tags as part of the way.







 [1] http://www.openstreetmap.org/browse/way/35515628
 [2] http://www.geobase.ca/geobase/en/view.do?produit=nrn


 On Fri, Jun 5, 2009 at 9:15 AM, Steve Singerssinger...@sympatico.ca wrote:

 I wanted to confirm that no one is actively working on the import for the
 040P Ontario area (waterloo, Cambridge, Woodstock).

 ___
 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] Geobase data vs. OSM data on import

[Steve Singer]

On Sun, 7 Jun 2009, Austin Henry wrote:


I encountered a bug in the roadmatcher matching where it would get confused 
and enter an infinite loop of sorts.

I patched it to detect the looping condition and break out.  The  version of 
the code I posted on github has this fix.

You can also get at a jar that works with openjump 1.3 + this change at

http://www.easy-share.com/1905578997/roadmatcher-1.4.jar

It might solve your problem.



 Hi all,

 I'm working on importing (most of) the 082E tile, and the part of the
 import process where you match roads in RoadMatcher is taking ages, even
 though there's very little data in OSM for the area (the reason I picked
 this tile, along with the fact that I used to live in the area).  The
 reason it's taking so long is the fact that the OSM data for Highway 3
 and the NRN data are very different in places.

 It seems like a combinations of things might have affected the data
 that's present now:
 - valleys throwing the GPS accuracy way out (or killing it entirely, and
  enabling the feature of garmin (and other?) units where it just
  interpolates until it gets a lock back);
 - low sampling frequency in the saved GPX tracks, which then got
  imported directly, or was traced at low zoom levels (the satellite
  data for most of highway 3 is low-res);
 - there are certainly other scenarios, but it's getting late and my
  brain's a bit fuzzy from staring at RoadMatcher for hours.

 It looks like the data was generally collected in one drive through by a
 non-local.  I'm not saying the data's crap, some of is really quite
 good.  But there are parts of it where it looks like a helicopter was
 used :)  And I'm not entirely sure how trustworthy the NRN data really
 is -- presumably it's good enough for the government to use, and most of
 it says the positional accuracy is 25m or less...

 So, what should I do for an upload?  Just upload the standalone portions
 like the process says, or should I upload all of the data, and delete
 the current OSM data where it's strange?

 The files for this tile are at
 http://drop.io/bvhw44o#list/sort_by_name/order_by_asc/60
 for those who might wish to look at it.  I can find bounding boxes for
 some examples if folks wish them.

 peace,
   Austin.

 -- 
 Build a man fire, he'll be warm for a day.
 Set a man on fire, he'll be warm for the rest of his life.

 ___
 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: [OSM-talk] How to present OSM to an audience of potential newbies?

[Steve Singer]

On Sat, 6 Jun 2009, Tim Morley wrote:

Some videos of OSM themed talks are available at [1] and [2]
You might get ideas from those.  [2] has starts out with a discussion on 
different freedoms a map might give (or not give).

Searching for OpenStreetMap on slideshare.net also gives many slidedecks 
that can give you ideas.

[1] http://www.fosslc.org/drupal/node/422
[2] http://hosting3.epresence.tv/fosslc/1/watch/145.aspx


Steve

 In a few weeks, I'll have the chance to present OSM to an audience of
 youngish (18-30), intelligent, open-minded people, who more than
 likely haven't yet come across the project. There may well be people
 who are familiar with free and open source software, but that
 probably won't be everybody present.

 Are there wiki pages, slideshows, materials, ideas, etc. that you can
 show me to help me prepare the presentation?

 Failing that, how do *you* explain to someone that uses Google Maps
 every day why you spend your time re-creating the same thing under a
 different name? (Slightly provocative question, perhaps, but it must
 be a very common one too -- what's your answer?)

 Thanks in advance for your help.


 Tim


 PS The audience is also very international, if that makes a
 difference -- mostly European (from all corners of the continent) but
 also with some Asians, South Americans, and Africans.

 PPS Sorry if this is a topic that's been covered before, but I've
 only just joined the list (and the project) and I couldn't
 immediately find anything relevant in the archives. If I've missed
 something, please just send me a URL and I'll do the rest. Cheers.


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



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

[Talk-ca] Ontario 040P

[Steve Singer]

I wanted to confirm that no one is actively working on the import for the 
040P Ontario area (waterloo, Cambridge, Woodstock).

It's listed on the wiki as being 'planned' from February but I'm guessing 
the wiki status is just out of date.

If I don't hear otherwise I'm likely to import this area overnight.


Steve


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

Re: [Talk-ca] 092g07 imported and uploaded

[Steve Singer]

On Mon, 1 Jun 2009, SteveC wrote:

 Stupid question, you guys importing addressing too?

Not yet.

A few provinces have address data as part of GeoBase (but most don't). 
However the StatsCan data does include block face addresses for all the 
provinces.

We've talked about importing offset address interpolation ways, someone just 
needs to write a script to do it. (might not happen until the base roads are 
imported in all the provinces, but on the todo list)

Steve

  
 On 31 May 2009, at 21:38, Michael Barabanov wrote:

  It is nice to see more people importing the GeoBase data.  Are you going 
 to be doing more areas in BC?
 
 Yes, starting with adjacent areas to south and east.
 
 Michael.
 
 On Sun, May 31, 2009 at 1:01 PM, Steve Singer ssinger...@sympatico.ca 
 wrote:
 On Sun, 31 May 2009, Michael Barabanov wrote:
 
 
 This includes parts of Burnaby, North Vancouver, Coquitlam, Port Coquitlam,
 Port Moody. See on OSM:
 http://www.openstreetmap.org/?minlon=-123minlat=49.25maxlon=-122.5maxlat=49.5box=yes
 
 Looks good.
 
 It is nice to see more people importing the GeoBase data.  Are you going to 
 be doing more areas in BC?
 
 Steve
 
 
 
 I've also captured my notes at
 http://wiki.openstreetmap.org/wiki/More_details_on_GeoBase_import_processand
 fixed minor details in
 http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature. If people
 think the additional notes are useful, I can merge this info into the
 description on the main Geobase import page.
 
 BTW, I've compared the NRN data to Canvec, and found that NRN data is more
 up to date (some new streets are only present in NRN).
 
 Michael.
 
 
 
 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ca

 Best

 Steve




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

[OSM-talk] OSCON anyone?

[Steve Singer]

Is anyone going to be in San Jose the Sunday right before OSCON?
The postgresql folks are looking for someone to give a lightning talk on OSM 
at PgDay (held in the San Jose convention center right before OSCON).

Anyone willing to do this should contact me off-list.

Thanks

Steve

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

Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...

[Steve Singer]

On Thu, 14 May 2009, Pieren wrote:

For the Canadian GeoBase road import I've been using a plugin to JUMP called 
RoadMatcher[1] to that detects common roads between two datasets. I've then 
been excluding ones that aren't likely to not cause conflicts.

A few more details at:
http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature

For land-use you could probably write some SQL queries that run against a 
osm2pgsql instance that find which of your land-use polygons don't intersect 
with existing osm land-use tagged areas.


I don't mind joining a mailing list for the data import working group, but I 
have enough on my plate with the various Canadian datasets that I won't be 
able to provide assistance scripting or importing to others for sometime. 
I'm not sure if I'll be able to make weekly conference calls either.


[1] - http://www.jump-project.org/portal.php?PID=PL


Steve

 Thanks for your suggestions.

 In our case, it is more about 80% of the import dataset that will
 stay. And we speak about e.g. forests, tree plantations, agricultural
 areas,etc which is a huge surface in France. Tha't why our preference
 would go to some solution making the import as much as possible
 automatic. For instance, a tool detecting conflicts between the new
 landuse polygones and existing landuse polygones, then splitting the
 data in two sets, one without conflicts which could be directly
 uploaded and one with conflicts which would require some individual
 investigation/edits.

 Pieren




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

[Talk-ca] OSM talk in Ottawa (pgcon)

[Steve Singer]

I'll be giving a talk on OSM and Postgresql in Ottawa on May 21'st at pgcon.
(http://www.pgcon.org/2009/schedule/events/141.en.htm)

Following my talk there will be a more general talk on spatial analysis with 
PostGIS.  PgCon is usually a fun confererence, if your in (or can get to) 
Ottawa you should attend.




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

Re: [Talk-ca] More uploads to Ucluelet, BC

[Steve Singer]

On Mon, 13 Apr 2009, Sam Vekemans wrote:

The roads around Ucluelet (and the rest of the 092c tile area) have been 
imported.

 Hi,
 Im wondering if someone is able to help and upload a sample of the
 geobase2osm roads data to the area?
 (I haven't yet learned how, but will) ... in the mean time it would be great
 to see a sample area done here. and perhaps run the new script with the
 StatsCan data. (if needed).    but i did remember how to make a Garmin
 map with the contours, so the OSM - Canada Map can be made :-)   (If anyone
 wants to help, please do speak up)

 Its 092c13 .. would be greatly appreciated.

 What I just discovered, is that facebook is a great tool to find people in
 the local areas. .. I just found local facebook groups, and im sure there
 would be 1 from each area.  So thats 1 way to get the word out to find local
 area people who are into using GPS and maps. (BTW, i'll physically be in the
 Ucluelet area myself, that's why i choose it) :-)

 The upload process is slow and steady, ... even after the canvec2osm script
 gets past the BETA stage... but i think that it's the best way to get it
 done.  .. manually uploading each feature area 1 at a time.  This way, it's
 VERY easy to not include shapes/lines/points that someone already spent the
 time and effort to map
 it.

 http://www.openstreetmap.org/?lat=48.9386lon=-125.5387zoom=14layers=B000FTF

 Thanks,
 Sam Vekemans
 Across Canada Trails



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

Re: [Talk-ca] Bulk Upload Update of CanVec GeoBaseNHN

[Steve Singer]

On Wed, 22 Apr 2009, Sam Vekemans wrote:

 Hi Steve,
 Thanks for updating the bulk_import.pl script.

I have not made any updates to bulk_import.pl, as far as I know it still 
isn't 0.6 compatible.

I did upload a python version (bulk_import.py) and Ivan has done a PHP 
version both of which should work with 0.6.


 Have you been able to get sample areas for each province done? (with the new
 addition of the stats can road names?)
 And so, for the area of Southwestern Ontario where GeoBase roads data has
 aleady been imported (as well as Quebec) and perhaps other places too.  I
 imagine that running the script again would automatically sence that roads
 already exist (from the pulled OSM file) and then just add in names where it
 sees none.

I wasn't planning on doing all the provinces (at least at this stage).  I was 
going to do the 092c13 area for you but then I find it is easier for me to 
focus on one province at a time.  I am still working on merging nodes at 
intersections in Alberta, API downtime has delayed this (and that 092 
update) a bit.

I'm also hoping others will pick up some provinces.


 I think just 1 test area for each province should be enough, so then the
 community and pick.. and complain :-) at it, (so to make minor
 modifications)


 Cheers,
 Sam Vekemans
 Across Canada Trails


Steve

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

[OSM-talk] Postgresql switchover

[Steve Singer]

Some of the Postgresql folks are looking for some info for advocacy purposes 
on the change to postgresql.

I suspect they want to know

A) The main reasons that motivated the change
B) Someone who they can quote as being from OSM. (ie for press materials/use 
cases)

If anyone is interested  reply directly to the below message, or if you'd 
rather me act as a conduit I can do that as well.

Steve

-- Forwarded message --
Date: Tue, 21 Apr 2009 13:09:08 -0700
From: David Fetter da...@fetter.org
To: Peter Childs peterachi...@gmail.com
Cc: pgsql-gene...@postgresql.org,
 PostgreSQL Advocacy pgsql-advoc...@postgresql.org
Subject: Re: [pgsql-advocacy] [GENERAL] PostgreSQL versus MySQL for GPS Data

On Tue, Apr 21, 2009 at 08:15:00PM +0100, Peter Childs wrote:
 Hmm Interestingly OSM have just switched from MySQL to PostgreSQL.

Can we get somebody from OSM to talk about this on the record?

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-advocacy mailing list (pgsql-advoc...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

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

Re: [OSM-talk] Update: add 'canvec:definition' tag?

[Steve Singer]

On Sun, 19 Apr 2009, Sam Vekemans wrote:

 Hi all,
 as im going through the rules.txt file and adding in the 'entity' and
 'value' tags, im thinking that adding the tag 'canvec:definition'
 would help.
 On some tags its a few lines of text, but it shouldnt go over the max
 number of characters permitted.

If the text of the canvec:definition tag is the same for each instance of a 
given feature type then it shouldn't be added to each way.  That type of 
thing is better on the wiki.

Steve



 Any thoughts? (before i spend uneeded time on it) :-)

 thanks,
 Sam


 -- 
 Twitter @acrosscanada
 Facebook Page 
 http://www.facebook.com/pages/Victoria-BC/Across-Canada-Trails/36142547420?ref=ts



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

Re: [Talk-ca] geobase ferry routes

[Steve Singer]

On Mon, 13 Apr 2009, Sam Vekemans wrote:

 Thanks,
 1 option is to use canvec since is only these few routes.
 What about 'blocked passage' has this been spotted in alberta?

 I'll add it as a bug anyway.

The number of routes is small enough that I don't think it matters where 
they come from, just that they get picked up at some point.

The reason some were excluded might have been because of an issue in the 
import script that existed for a time (but I haven't yet confirmed that 
that).

I am not importing any block passage info.



 sam



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

Re: [Talk-ca] More uploads to Ucluelet, BC

[Steve Singer]

On Mon, 13 Apr 2009, Sam Vekemans wrote:

 Hi,
 Im wondering if someone is able to help and upload a sample of the
 geobase2osm roads data to the area?
 (I haven't yet learned how, but will) ... in the mean time it would be great
 to see a sample area done here. and perhaps run the new script with the
 StatsCan data. (if needed).    but i did remember how to make a Garmin
 map with the contours, so the OSM - Canada Map can be made :-)   (If anyone
 wants to help, please do speak up)

 Its 092c13 .. would be greatly appreciated.

I can import that area for you, but I might not be able to get it imported
until early next week.

If someone else wants to do it before then let me know.


 http://www.openstreetmap.org/?lat=48.9386lon=-125.5387zoom=14layers=B000FTF

 Thanks,
 Sam Vekemans
 Across Canada Trails


Steve

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

Re: [Talk-ca] Provincial Borders

[Steve Singer]

On Wed, 8 Apr 2009, Sam Vekemans wrote:

 Hi,
 in some spots (vancouver island) i see that the line actually cuts
 through small edges of land.

Is the border wrong, or is the polygon in that draws the land/island wrong? 
But openstreetbugs.org is probably a good  way of kicking track of these 
places until somene can investigate them further.




 Odds are that International waters starts at a certain distance off-shore.

 I will be importing coastal islands and nav-aids such as lighthouses and 
 buoys.

 I think its best to notify geobase as they can move it in the GeoBase set.
 Then once they update it, we can us it to trace the fixes.
 We can use OpenStreetBugs.org and pinpoint the spots that need to be fixed.

 There arn't TOO many of them, so it should be fine.

 cheers,
 Sam

 ___
 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: [OSM-talk] Addr:streetnumber:first;last:left;right

[Steve Singer]

On Tue, 7 Apr 2009 marcus.wolsc...@googlemail.com wrote:

 You said you had these housenumber-data for the segments, not for the whole
 way, did you?

 Then there is no issue with curvy roads.

Yes

 Well, at least add your data to the way as canvec:housenr_left_start=
 and similar, so the data does not get lost.

The source dataset from the government isn't likely to go anywhere so 
I'm not too concerned about it getting lost.


 If we want to use a Karlsruhe scheme then this will need a script similar
 to
 what the ump2osm  is doing, I think we are best waiting till someone
 can do that with offsets and relations to the road (the complexity of the

 script will probably be comparable to the ump2osm script).

 What language do you need it to be in?


So far the import scripts I've been using are in python.

 What data-model are you using for the osm-data
 (how can the scripe get the way?
 ...and the nodes for the way's waynodes?
 how can it output new osm-entities?
 how can it search an area if some osm-entities are already present?)


For the geobase roads I am using a program called RoadMatcher that is a 
plugin to JUMP for detecting roads in that are likely to already be in OSM. 
I then import the geobase roads  and tag each way with the uuid 
(geobae:uuid) that mostly identifies the source road segment. I exclude
the roads flaged as already being in OSM.

Once I have the road network dealt with I (or another eager volunteer) can 
create the address nodes+interpolation ways using some of the methods 
discussed on the thread.  Connecting the interpolation ways to the 
previously imported nodes with a realtion shouldn't be hard.  I know the 
uuid that the address applies to. I can get the way_id by searching a local 
copy of the OSM database for that geobase:uuid.  A script can then 
get/edit/upload the existing way though the API.

The script we are using for importing the base roadnetwork is available 
http://svn.openstreetmap.org/applications/utils/import/geobase2osm/

I am currently working on another script to fix some issues in the some of 
the roads imported so far (a bug prevented some intersections from sharing a 
node). This will use the local lookup, query ,edit technique I discussed 
above.


Steve


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

Re: [Talk-ca] [OSM-talk] Addr:streetnumber:first;last:left;right

[Steve Singer]

On Tue, 7 Apr 2009 marcus.wolsc...@googlemail.com wrote:

 You said you had these housenumber-data for the segments, not for the whole
 way, did you?

 Then there is no issue with curvy roads.

Yes

 Well, at least add your data to the way as canvec:housenr_left_start=
 and similar, so the data does not get lost.

The source dataset from the government isn't likely to go anywhere so 
I'm not too concerned about it getting lost.


 If we want to use a Karlsruhe scheme then this will need a script similar
 to
 what the ump2osm  is doing, I think we are best waiting till someone
 can do that with offsets and relations to the road (the complexity of the

 script will probably be comparable to the ump2osm script).

 What language do you need it to be in?


So far the import scripts I've been using are in python.

 What data-model are you using for the osm-data
 (how can the scripe get the way?
 ...and the nodes for the way's waynodes?
 how can it output new osm-entities?
 how can it search an area if some osm-entities are already present?)


For the geobase roads I am using a program called RoadMatcher that is a 
plugin to JUMP for detecting roads in that are likely to already be in OSM. 
I then import the geobase roads  and tag each way with the uuid 
(geobae:uuid) that mostly identifies the source road segment. I exclude
the roads flaged as already being in OSM.

Once I have the road network dealt with I (or another eager volunteer) can 
create the address nodes+interpolation ways using some of the methods 
discussed on the thread.  Connecting the interpolation ways to the 
previously imported nodes with a realtion shouldn't be hard.  I know the 
uuid that the address applies to. I can get the way_id by searching a local 
copy of the OSM database for that geobase:uuid.  A script can then 
get/edit/upload the existing way though the API.

The script we are using for importing the base roadnetwork is available 
http://svn.openstreetmap.org/applications/utils/import/geobase2osm/

I am currently working on another script to fix some issues in the some of 
the roads imported so far (a bug prevented some intersections from sharing a 
node). This will use the local lookup, query ,edit technique I discussed 
above.


Steve


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

Re: [Talk-ca] [OSM-talk] Addr:streetnumber:first;last:left;right

[Steve Singer]

On Mon, 6 Apr 2009, Sam Vekemans wrote:

 addr:alternatenumber 
 house number
 If a object has two numbers. Better use addr:housenumber=first;second
 ***
 So the line can show a long stretch from second where it would be
 the 'last'?  Would this work?

Drawing a long straight line from the first to last end points would 
probably work fine for address interpolation type applications (if the 
application projects the point onto the road) but it you wouldn't want the 
renderer to draw that line, for a curved road it would look really bad.

 And for the off-set, ill leave that for the expert. ... since the
 canvec2osm (using simple java) script is not really 'automatated'.
 .the geobase2osm (using python) script is.

If we want to use a Karlsruhe scheme then this will need a script similar to 
what the ump2osm  is doing, I think we are best waiting till someone 
can do that with offsets and relations to the road (the complexity of the 
script will probably be comparable to the ump2osm script).

If we want to attach the tags directly to the road nodes themselves then you 
would need a script that get add these tags to existing nodes (doable, but 
neither canvec2osm or geobase2osm alter existing nodes/ways)



 So I think best option is still the same, keep the streetnames.osm
 files in the canvec2osm script (but as a reference,  not to be
 imported), and let the geobase2osm script deal with it.. So hopefully
 we can help out SteveS with the scripting as much as we can.


One concern I have with including data you don't intend to import is that 
people might spend time reviewing it along with the other data you want to 
import not realizing that some of it needs review but other parts are just 
for reference.


 Thanks
 Sam Vekemans
 Across Canada Trails


Steve

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

Re: [Talk-ca] [OSM-talk] Addr:streetnumber:first;last:left;right

[Steve Singer]

On Mon, 6 Apr 2009, andrzej zaborowski wrote:

 I'm not completely sure either representation is better... maybe both
 types should be standardised - the UMP project makes maps particularly
 for Garmin devices so apparently if you upload your map into your
 Garmin receiver and ask it to route you to a given housenumber, it
 will want to know the first and last housenumber for all way segments,
 and will interpolate the position...

The bad part of standardizing on both ways is that applications that use OSM 
data for routing or rendering addresses would need to support both ways.

 now I'm sure that at some point a lot of people will want to use OSM
 on the Garmins (very few people do now) and the converter will have to
 translate the Karlsruhe scheme back into the Garmin/canvec/geobase
 scheme.  This can be done by converting the addr:interpolation ways
 into new garmin ways that will have the address information but will
 not be routable - but then they will be disconnected from the road
 network and the routing may fail.  The other option is to *project*
 the lateral addr:interpolation ways onto the street segment, but this
 is a little more complex to implement (imagine zigzagging streets and
 zigzagging addr:interpolation ways)

If the interpolation ways model the geometry of the original way just offset 
by some factor then the interpolation ways wouldn't cross the street 
segment.  If your source for the addresses is the same as the source for 
your roads (as is this case with geobase) then this isn't hard to implement 
but results in a lot of extra nodes.  If your trying to overlay some address 
data onto existing roads this becames a bit harder but is still doable (get 
the project your addresses onto the road segment, and duplicate+offset it).

The big concern I have with having the interpolation ways model the geometry 
of the original road is that we are increasing the number of nodes (and 
ways) required by a factor of 3.  One set of nodes + way for the road, a 
second set all shifted x meters to for the right side and a third set 
shifted -x meters for the left side.


Steve

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

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

[Steve Singer]

On Wed, 1 Apr 2009, Sam Vekemans wrote:


 And Steve, my plan is still to wait till you run the geobase2osm script
 (unfortunatly i dont know how too),,, before loading any of the canvec data
 on top.   If you have a chance, please let me know if it would be fine to be
 importing the data for .. those areas of
 very very little to know OSM data.?? .

 And everyone,.. since the geobase2osm script would detect that canvecROADS
 were already imported, it would look at them the same way as user created
 OSM Roads.???


I'm somewhat confused by the above two paragraphs, they seem to contradict
each other.  Is it the case that:

1. Your not going to import the road layer from canvec.  In this case it 
doesn't matter if you import the canvec data before or after the geobase 
roads are imported.   Campgrounds, power lines, buildings etc... won't 
conflict with roads (I won't exclude roads based on a power line running 
next to it).

2. Your going to import the canvec roads, if so then any roads you import 
before I run roadmatcher should just result in that road being excluded from 
the geobase import (it will be treated just like any other OSM road).  If I 
do the geobase import first then you'll need to find a way to detect 
conflicts.

Which one is it?


 Thought on that anyone?

 Cheers,
 Sam Vekemans
 Across Canada Trails



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

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

[Steve Singer]

On Wed, 1 Apr 2009, Michel Gilbert wrote:


 I decided to check other locations in Alberta and it seems that the problem
 is everywhere. Was anyone aware of that problem ?


No, I thought the ways within the same import block were sharing nodes.  In 
fact it worked like this at one point, 
http://www.openstreetmap.org/?lat=53.0304lon=-117.3277zoom=14

Somewhere along the line I must have broken something in my script. I will 
write a script to find + merge the geobase imported nodes.


Good catch

 Michel



 http://sites.google.com/a/acrosscanadatrails.com/www/Home/canvec2osmsamplearea082h05PincherCreekAB.zip


 Look forward to the feedback,
 Cheers,
 Sam


 -- Forwarded message --
 From: Sam Vekemans acrosscanadatra...@gmail.com
 Date: Wed, Apr 1, 2009 at 11:35 AM
 Subject: canvec2osm sample area tofino BC _with roads
 To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org, Michel Gilbert 
 michc...@gmail.com, Steve Singer ssinger...@sympatico.ca, Richard Weait
 rich...@weait.com


 Hi all,Yupee,
 I got the sample area saved (not yet posted to OSM) of Tofino, BC
 You can view the zip file containing the .OSM files.

 http://sites.google.com/a/acrosscanadatrails.com/www/Home/canvec2osmsamplearea092f04tofinoBC.zip


 The addition of the CanVec Roads looks good, so far.  But (of course) would
 need to be fixed up.
 I compared the geobase2osm roads, and i see that i have included a few more
 tags that were not included in the geobase2osm script.

 For now the rules.txt file is available in the same place.
 http://docs.google.com/Doc?id=d2d8mrd_179gnhs54cwhl=en

 I'm now working on the wiki chart, to show all of the tags that i use. ...
 in the next few days it should be done. :-)

 ... i found this way (adding it to canvec2osm) rather than creating the
 canvecROADS2osm script seemed to be easier.  Didn't take much longer to run
 the script.

 For those who can read the rules.txt file let me know if you see any
 errors.  (even if i already spot them, it's good to confirm what the right
 tags should be.

 And Steve, my plan is still to wait till you run the geobase2osm script
  (unfortunatly i dont know how too),,, before loading any of the canvec data
 on top.   If you have a chance, please let me know if it would be fine to be
 importing the data for .. those areas of
 very very little to know OSM data.?? .

 And everyone,.. since the geobase2osm script would detect that canvecROADS
 were already imported, it would look at them the same way as user created
 OSM Roads.???

 Thought on that anyone?

 Cheers,
 Sam Vekemans
 Across Canada Trails


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




 -- 
 Michel Gilbert



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

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

[Steve Singer]

On Wed, 1 Apr 2009, Sam Vekemans wrote:

 Thanks,
 the canvec roads think  act like Q-tips. And unfortunatly, i cannot
 run AutoMatch, so it would be best for geobase2osm to be run 1st. Then
 use the canvec roads as an overlay. (to help users as a guide to know
 where to Stretch/move the intersecting nodes too.)

I don't understand what you mean by Q-tips.  If your planning on using the 
roads from the geobase dataset then I'm not sure why your going to use the 
canvec ones as an overly.  From a geometric  completeness point of view 
aren't they the same (since they both come from the same dataset).


 Does the geobase script account for the
 AdressRangeFirst/last/left/right data fields?

 If it doesnt, then that needs to be handled.

No I don't currently have any scripts that deal with address range data.  We 
had an email thread about this a week or two ago.   There was some debate as 
to how address interpolation should be represented for block face data. 
Making Karlsruhe work for block face data might take a bit of work. I
haven't had time to look at this since (and it is unlikely I will get to 
this in the next few weeks)


Steve

 Cheers,
 Sam

 On 4/1/09, Steve Singer ssinger...@sympatico.ca wrote:
 On Wed, 1 Apr 2009, Sam Vekemans wrote:


 And Steve, my plan is still to wait till you run the geobase2osm script
 (unfortunatly i dont know how too),,, before loading any of the canvec
 data
 on top.   If you have a chance, please let me know if it would be fine to
 be
 importing the data for .. those areas of
 very very little to know OSM data.?? .

 And everyone,.. since the geobase2osm script would detect that canvecROADS
 were already imported, it would look at them the same way as user created
 OSM Roads.???


 I'm somewhat confused by the above two paragraphs, they seem to contradict
 each other.  Is it the case that:

 1. Your not going to import the road layer from canvec.  In this case it
 doesn't matter if you import the canvec data before or after the geobase
 roads are imported.   Campgrounds, power lines, buildings etc... won't
 conflict with roads (I won't exclude roads based on a power line running
 next to it).

 2. Your going to import the canvec roads, if so then any roads you import
 before I run roadmatcher should just result in that road being excluded from
 the geobase import (it will be treated just like any other OSM road).  If I
 do the geobase import first then you'll need to find a way to detect
 conflicts.

 Which one is it?


 Thought on that anyone?

 Cheers,
 Sam Vekemans
 Across Canada Trails






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

Re: [Talk-ca] Merging OSM + Geobase

[Steve Singer]

On Fri, 27 Mar 2009, William Lachance wrote:


 I'm not so sure that we do. :) I did try to read the archives before
 posting here, and couldn't find any approach which really corresponded
 with my own. I could be missing something important, but I also don't
 really see the harm in giving the idea a try. It's basically just a few
 evenings of python scripting for me, with the potential payoff of more
 accurate and complete OSM data for at least the Halifax Regional
 Municipality (and possibly other areas as well) than what you'd get with
 alternative methods.

If you have the time+skills to put together a script that tries to do this 
then I'd encourage you to give it a shot. With volunteers it is somewhat 
difficult to volunteer or propose work for others.  It isn't that we don't 
want the OSM and geobase roads to be connected, it is more that only few 
people working scripts and no one has yet raised there hand to do these 
things.


 Obviously this approach could be combined with others that have already
 been tried-- I'm definitely not telling people to stop whatever they're
 doing to wait for me. ;)

The approach I think you are describing in your other message and  is 
probably worth investigating is:

For each segmen in geobase
If an end of the segment forms a junction with another segment
If that segment is a OSM segment(see 1)
AddNode()
endif
endif
endfor

where addNode()
adds a node onto the geobase segment that is on the osm segment.



In the following sample you would need to find x, where the two intersect.

 *
 * 
a- x -b
*
  * *

My guess is that you would calculate x as the point on either the OSM line 
that minimizes the distance between the geobase line and x but that is just 
a guess.   You might be inserting x in the middle of both lines, but there 
is probably a way to find this insertion point.



I suspect you'll find more complications as you try this.

(1) - The process for excluding OSM ways with roadMatcher also can find the 
existing OSM way that corresponds to a geobase segment for some percentage 
of roads (30%-75% I'd guess but it depends on the area)
I can send you a xml file with matches if you don't want to mess with road 
matcher.




 -- 
 William Lachance wrl...@gmail.com


 ___
 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] Next road import area

[Steve Singer]

On Wed, 25 Mar 2009, Jonathan Stewart wrote:

 On Wed, Mar 25, 2009 at 7:26 AM, Steve Singer ssinger...@sympatico.ca wrote:

 This will be an impediment to importing, for sure.  I have maps of
 Winnipeg i could get names from, but rural roads would be quite
 difficult.

I have an idea on how we can extract the road names from a StatsCan dataset 
for many roads.  I'll post most details after I've done some more work on 
it.

Steve


 I may well try the Postgres method, we've got a postgres server
 running which could be used. (and yeah i know i could run one locally
 too).

 Thanks for your help.

 snip the rest



 -- 
 Jonathan



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

[Talk-ca] Next road import area

[Steve Singer]

Now that I've finished importing the roads in Albera I'm deciding on the 
next region I'll tackle.

Is anyone else actively working on importing roads? (I know John has been 
working in south-western Ontario). I don't want to duplicate efforts.

I am considering:

-Nova Scotia 
-British Columbia
-Some sections in Ontario

If anyone is working on (or has been thinking of getting started on) any of 
these drop me a note.







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

[Talk-ca] Address ranges

[Steve Singer]

I'm starting to think about how we might want to import address range data 
from Geobase/Statscan into OSM.

The Karlsruhe schema
http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema
 
seems to be the most popular OSM method of adding address data.

It uses a node (that is not part of the road) that is placed at the location 
of the house/building that address information is known about.  These nodes 
are then connected with interpolation ways.

The GeoBase address data (and the StatsCan data) give block face addresses. 
The datasets essentially say for this block(road segment) the first house is 
100 and the last house is 120; along with some interpolation data.  We don't 
get the coordinates of any houses/addresses on the street.

Consider these example

Say we have two streets, Main Street (--) and First Street (***) made up of 
4 road segments.

 *(3)
 * 
--(1)--Main Street--+---(2)-
 *
 *
 *(4)


The block face based data we get might tell us that road segment (1) is 
100,150 on the right side, 101 to 102 on the left side

Segment (2) is 152 to 160

Segment (3) is 10 first street to 14 first street

and segment (4) is 16 first street to 20.

If we wanted to translate this to the Karlsruhe schema we could create nodes 
at the start and end of each road segment(based on the geometry coordinates 
of the road from the NRN/stats can data).

These leads to the following issues:
1. Do we create the address nodes on the street, in which case they would 
occupy the exact same coordinates of the nodes that make up the road itself? 
Or do we try to offset the address nodes to the left/right of the roads by 
some artificial amount (say 3 meters).

2. The point on my diagram marked (+) is an intersection of 4 road segments. 
Our block face data gives us 4 addresses at that single point(8 if you 
count both sides of the road).  This isn't a problem if we are coming up 
with offsets.


When we import address data I am thinking that we would import it for all 
roads, not just ones the ones that came from geobase.  Since address 
nodes/ways don't' get connected to the roads anyway I don't see the harm in 
adding address for pre-existing roads or ones that the import skipped. 
There will be some positional consistency issues but we are going to have 
those anyway if we are offsetting the nodes by some arbitrary amount.

In cases where we are able to attach the road(way) in OSM with the address 
then we can create an optional relation linking them.

If anyone is aware of another data import that used a block based address 
source (versus a data source that has an entry for each lot on the street) 
I'd appreciate a pointer to it.

Thoughts?


Steve



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

Re: [Talk-ca] FW: Road Network File license conflict?

[Steve Singer]

On Wed, 4 Mar 2009, Richard Weait wrote:

 Dear All,

 Good news.  We may use the StatCan Road Network File under the
 Unrestricted Use Agreement.

 So does this get us road names in other provinces?

This helps.

As Dan pointed out we probably want to use RoadMatcher so we can use the 
geobase geometries with the statscan names.  I will try to add support to 
geobase2osm to attach names ways from a roadmatcher output file.

This also means that mappers who have been tracing data from Yahoo can 
download the statscan shapefiles+a viewer and use this as a source of names 
for roads that have already been traced.

Steve




  Forwarded Message 
 From: marie-josee.lalo...@statcan.gc.ca
 To: rich...@weait.com
 Subject: Request #2008398 - FW: Road Network File license conflict?
 Date: Wed, 4 Mar 2009 10:21:27 -0500

 Hello Mr. Weait,

 Yes, your request is permissible with the Unrestricted Use agreement.
 I believe the copyright notice pertains to the content of the
 reference guide and not to the actual product.

 [copy of s3.0 Licence Grant removed for space]
 -Original Message-
 From: Richard Weait [mailto:rich...@weait.com]
 Sent: February 27, 2009 5:12 PM
 To: infost...@statcan.ca
 Subject: Road Network File license conflict?

 Dear Statcan,

 I'm a contributor to OpenStreetMap, an international project to
 provide
 maps and mapping tools to people around the world.  There are over
 95,000 contributors around the world.

 The Canadian OpenStreetMap community is interested in including
 information from Statistics Canada in OpenStreetMap but we found a
 possible contradiction in the permitted use of the Road Network File
 that raised questions.  From an abundance of caution, I write to you
 for clarification.

 The Unrestricted use license agreement[1] appears to permit commercial
 use of the derivative product while the more information page
 specifically excludes commercial use[2].

 I hope that you can clear this up for us so that we may begin the
 process of importing the Road Network file and merging the data with
 OpenStreetMap.

 Perhaps the information page refers to the Statistics Canada web site
 while the unrestricted use license agreement refers to the Road
 Network file?


 Best regards,
 Richard Weait,

 OpenStreetMap data contributor
 [1]http://geodepot.statcan.ca/2006/Reference/Freepub/92-500-GWE/2008001/agreement-en.htm
 [2]http://geodepot.statcan.ca/2006/Reference/Freepub/92-500-GWE/2008001/info-en.htm








 ___
 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] NRN Map chart CanVec Updat

[Steve Singer]

On Wed, 25 Feb 2009, Sam Vekemans wrote:

 hi,
 Yes, it has been discussed. (somewhere back in the archives)
 It's on my list of things todo.
 Make a wiki page about this issue, and what the answer (consensus is)

At one point the statscan road network was licensed under terms that 
prevented commercial use (something that is clearly incompatible with OSM).

However, when I look at 
http://geodepot.statcan.ca/2006/Reference/Freepub/92-500-GWE/2007001/agreement.htm
 
I don't seem to see such a clause.  Has the licensed changed?  Is this 
license compatible with OSM? (It's worded differently than the GeoBase/NRN 
license)





 cheers,
 sam


 On 2/25/09, Michael dos Santos mee...@hotmail.com wrote:
 Has anyone looked at pulling road names out of the StatsCanada 2005 Road
 Network?  The linework is terrible but useful for names and highway/road
 numbers.



 http://geodepot.statcan.ca/Diss/2006Dissemination/Data/FRR_RNF_e.cfm









 Michael



   _

 From: talk-ca-boun...@openstreetmap.org
 [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans
 Sent: Tuesday, February 24, 2009 3:22 AM
 To: John Peterson; talk-ca@openstreetmap.org; Steve Singer; Michel Gilbert
 Subject: [Talk-ca] NRN Map chart  CanVec Update



 Hi,

 It looks like your working more on the 040 area. Awesome!

 Perhaps it would be best to keep it to 1 line, and just add in what tiles
 your working on.

 My concern is that this chart will get too big.



 As you might be aware there is an option to show the unnamed roads.. as
 fixme=no name so then on the OSM map layer, all the roads that need to be
 named are highlighted.



 I have now been able to make the CanVec2osm script work, so it's also
 possible to view everything that canvec has to offer shown as individual OSM
 files.



 The only thing that it doesn't do is compare with existing data directly.
 But fortunately, this doesn't include roads.  The roads DO exist, but
 because road names are not available AND the data isn't as accurate, it's
 not used, nor is any other feature that is already part of GeoBase.



 So far, the script doesn't include all the features, yet, but enough to get
 an idea of how the features will get shown.



 The progress of this import will also be shown in a similar fashion, so i am
 trying to match as much as possible.



 I wont actually start the import until, the whole script is done (obviously)
 :-) ... but until i get the OK from lots of mappers that all the tags are
 there as they should be.



 Cheers,

 Sam



 ___
 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] Jasper, Hinton and Edson

[Steve Singer]

My import of road data in Alberta is getting into areas that seem to have 
some local mappers (versus much of northern Alberta that seemed pretty 
sparse)

http://www.openstreetmap.org/?lat=53.498lon=-116.498zoom=10layers=B000FTFT

isn't a bad link for seeing some of what I've imported.  Jasper, Hinton and 
Edson are some examples of communities that were already well mapped 
and the import has expanded on.

You can view the NRN roads excluded(left out) of the import at 
http://www.mediafire.com/?ng40oxg4ztx  (this can be opened in JOSM). I am
hoping some mappers will integrate some of the roads that were excluded and 
start connecting the previous OSM ways with the imported roads (where 
required).  I am hoping the excluded file makes this process easier than it 
was for Fort McMurray.


Also if anyone is familiar with the Jasper area I'm kind of curious what 
this 
http://www.openstreetmap.org/?lat=52.84602lon=-118.07543zoom=15layers=B000FTFT
 
is? If you know the answer feel free to add the proper tag.

Steve




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

Re: [Talk-ca] OSM Geobase import: giving a try

[Steve Singer]

On Sun, 15 Feb 2009, Frank Steggink wrote:

 Hi,


 I've tried to digest the wiki pages and e-mails, but it's quite a lot of
 information. It is especially hard to identify what information is still 
 current
 and what is obsolete. Hopefully you can help me getting started by answering a
 couple of questions. I understand that the NRN data has the highest priority, 
 so
 I'll focus on that.

Yes the wiki needs a cleanup, I've been hoping someone else would do it 
since that doesn't seem to be happening I will try to find sometime soon to 
delete all obsolete information from the wiki pages.


 1. Is there an agreed set of tags which need to be imported? There
 Geobase_NRN_-_OSM_Map_Feature page on the wiki lists a huge list of tags. 
 Should
  they all be converted? I assume we would like to keep the imported data
 consistent, although there will be differences between different provinces, 
 and
 existing data will also be different.
 a. What is the final resolution about NID's? Do they need to be kept?


Yes please try to keep nids for data that actually comes from geobase.
Not importing could limit us in the future.




 b. How can we guarantee that the final import will be consistent? (See 
 also
 my first question.)

Depends what you mean by consitent.
1. Using consistent tags for things, the best way to ensure this is to look 
at what others are doing and share your scripts.

2. data consistency, ie roads line up and are joined between different 
imports or between the existing and geobase data.  Right now we have no 
automated consistency tools, we are depending on people to manually line 
up/connect ways post import.


 2. Do I have to use existing software / processes, like RoadMatcher, or can I
 develop a way to import data in a way that will suit me the most?
 a. For software it makes most sense to reuse what is already available, 
 and
 adjust it when necessary.
 b. I'm actually missing a best practice page. It is not evident what the
 most efficient process is, but that's also likely subject to personal taste /
 skills.

You are free to use your own processes and software.  I don't think any two 
people are doing the exact same thing for importing.  This is the process I 
follow

You don't need to use roadmatcher, you just need to have some method of 
avoiding hundreds of duplicate roads.


For comparision purposes what I've done with the larger areas in Alberta:

1. Populate a postgis database with the NRN shapefile
2. Populate a postgis database with the OSM data using osm2pgsql
3. Generate a NRN and OSM shapefile for the area that I'm interested in
using pgsql2shp and some SQL queries. I handle reprojection during this
process as well (lately I've been reprojecting into meters)
4. Import both shapefiles into jump and automatch with roadmatcher
5. Export my results
6. Run geobase2osm on the NRN GML file(yes I had to download the NRN data
twice) and produce a standalone file
7. Review the standalone file in JOSM
8. Upload the standalone file with bulk_upload.pl
9. Manual fixup in JOSM.



 3. Is there an existing tool to cut the NRN data files in tiles? Or does 
 someone
 host the NRN data which are already cut into tiles? Or is it preferred to use
 the Ibycus topo maps (and convert them to OSM)?
 a. Do the Ibycus maps contain all attributes? I don't think so, since
 they're created specifically to be used by GPSs.


Do not use any of the Ibycus stuff the import the licenses are not 
compatible. Do not use ibycus in the geobase import.  Someone should have 
removed these references from the wiki a long time ago.  I will try to do it 
soon.

The geobase2osm.py script accepts a -b parameter which is a file containing 
containing a bounding area (it doesn't need to be square),

POLYGON((-120 54.961853027,-120 56,-118 56,-118 54.961853027,-120 
54.961853027))

I use conditions on my postgis WHERE clause to cut the data down in the 
shapefiles I generate for roadmatcher.


 4. Since it seems there are several different individual import /
 experimentation processes going on, many imports will have to be rolled back.
 (I'll create a new OSM user, so my changes will be easily detectable.) Is 
 there
 a test server available?


I just viewed/posted my initial .osm files in JOSM and when people where 
happy with them I did an import to a small isolated area.  Using a seperate 
userid is a good idea.

You can get the latest version of geobase2osm.py here, a number of people 
have used this as the basis for their custom procedures.

http://svn.openstreetmap.org/applications/utils/import/geobase2osm/geobase2osm.py
Steve

 [Not in the mail to Michel:]
 Based on the gathered information I've developed a workflow based on PostGIS. 
 I
 still need to test it, but if this workflow is useful, I'll share it with you.
 It will involve a certain degree of manual checks, but my experience is that
 data imports always need close attention. It is very easy to mess up things. 
 We
 

Re: [Talk-ca] OSM Geobase import: giving a try

[Steve Singer]

On Sun, 15 Feb 2009, Frank Steggink wrote:

 Hi Steve,

 In what way would it limit us? When we'll receive a new dataset from Geobase? 
 Or do you hint towards other datasets which are linked to the NID? In that 
 case that additional data can't be linked to existing database, because that 
 doesn't contain the NID attributes.

Mostly when we receive geobase updates.

Consider what should happen when as geobase releases road name data for 
provinces that have already been imported.  We will just need a script that 
finds the OSM way that is tagged with a particular geobase:uuid and add in 
the name tags from the geobase update.  If we don't have the uuid in the OSM 
data we'd need to figure out some other method.

Also we think about what happens when a road crosses two of the artificial 
tiles we dividing the import process across,  if each road as a unique NRN 
id you can easily excluded the nids already imported in the adjacent tile 
from the current one.

I only reason to not include it would be to save a few bytes of space.


 I actually wanted to use PostgreSQL/PostGIS, but it seems that no OSM data 
 can be exported from it. At least not when OSM data was previously imported 
 through osm2pgsql. Maybe it will work to keep the Geobase data in Postgis, 
 export as OSM, and then apply some postprocessing (fixing in JOSM).

I've been exporting OSM data from PostGIS without issues.
I've added some more detailed steps at 
http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature

I export the OSM data from PostGIS as a shapefile, I only use this as an 
input to road matcher (I only need a few fields).  I don't think the data
from osm2pgsql can be used to regenerate .osm files though.

 I'm going to try to generate buffers around the imported road data from OSM, 
 and will use it to clip away any Geobase data (NRN) which is entirely within 
 a certain distance from the OSM data. And then export it to OSM. I'll need to 
 work it out further, using my test area. I think that a buffer of 10 or 20 
 meter is enough.

I thought about using buffers initially but then I came across road matcher.

10-20 meters tends to work for OSM data from GPS traces but the roads from 
low-res imagery (often of highways in rural areas) often can be off by 100 
meters.

 One final question: what is the accuracy of the Geobase data? Is it worse, 
 comparable, or better than typical GPS tracks? The roads I've drawn so far 
 match the Yahoo imagery quite well, although usually there is a slight offset 
 of a few meters.

The Geobase data comes from different sources.  Some of it is from GPS, 
other data is from Vector files and some from imagery.  My guess is that all 
of it is more accurate than the low-res pictures Yahoo provides in Northern 
Alberta.

My guess is that most of the geobase GPS data is better/comparable to the 
typical OSM mapper GPS data, the vector data doesn't seem to be as good (and 
I've found instances in Ontario where the geobase vector data shows 
roads/intersections that don't exist).   The geobase documentation lists 
accuracy/precision somewhere but I can't recall what they claim.




 Regards,

 Frank


Steve


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

Re: [Talk-ca] Geobase2osm.py update

[Steve Singer]

I have checked a new version of geobase2osm.py into the OSM SVN repository.

-Add support for creating .standalone and .excluded files
  based on output generated from the RoadMatcher application
-Using OfficialPlaceName for is_in tags
-Added geobase:acqisitionTechnique
-Added geobase:datasetName
-Fixing Route numbers  names to deal with Ontario None
-Additional names in the geobase data get stored in alt_name per
  talk-ca discussion

This reflects work done during the Fort McMurray and 084 tile imports


Steve

On Wed, 11 Feb 2009, Jason Reid wrote:

 Steve Singer wrote:
 On Tue, 10 Feb 2009, Sam Vekemans wrote:
 
 Hi all,
 3 things:
 1- im wondering if the python script that is available in the svn has
 been updated lately? I dont see a direct link to it on the wiki page,
 so im not sure.
 
 I don't think the version in svn has been updated in a while.
 I don't have access to commit to the OSM svn repo, if someone has time to 
 checkin the latest version of geobase2osm.py that I've been using I can 
 send them the file.
 
 Steve
 
 
 I haven't had time to commit the last version you sent me. If you want access 
 to commit it yourself fire an email off to Tom Hughes and ask if he can set 
 you up with an account to commit to the proper spot in the repo.

 -Jason Reid



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

Re: [Talk-ca] Open Source Software Road Matcher

[Steve Singer]

On Wed, 21 Jan 2009, Michel Gilbert wrote:



This IS the RoadMatcher tool I've been using for finding standalone ways. 
I have been using the stock roadmatcher plugin in JUMP and OpenJump (I have 
not changed any code in it).

I think I sent that link below when I started looking at it (I think I added 
it to the wiki at some point as well).

I typically have been using these settings for the AutoMatch
Minimum Line Segment Length: 5.0E-7
Standalone Minimum Distance: 5.0E-4
Matched Maximum Distance: 5.0E-4

When all the data has been reprojected to epsg:4326
I suspect these settings could be tuned more.





 Hi all,

 I put aside the NID issue for awhile to talk about my new findings. There is
 Open Source Software project JUMP that provides Road Matcher tools. JUMP is
 a Java platform application to edit geospatial data and is mainly developed
 by Vivid Solutions, a company from Victoria BC. The Road Matcher tools
 include: conflation, tolerances, transfer attributes, transfer vertex, save
 the matching result. JUMP is a graphic editor so you execute the Road
 Matcher within JUMP. There are tools to complete the matching manually.

 JUMP reads and wirtes in shape files. You can download JUMP and the Road
 Matcher 
 herehttp://www.vividsolutions.com/projects.asp?catg=spageocode=roadmatcher#down_1_4.
 The download come with very good documentation. It is easy to install and
 run. I'll give it a try.

 Cheers,

 Michel



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

Re: [Talk-ca] Question about NIDs

[Steve Singer]

On Wed, 21 Jan 2009, Richard Degelder wrote:

 The other option is to take the longer ways and have a relationship
 attributed to the appropriate section which will have the NID.  This
 would likely not be frequently disturbed by new editors to the map, but
 the need for making this automatic in some way will make the script a
 lot more complex.  And we are going to have to find a way to combine the
 short ways generated by Steve's scripts into a longer way and that
 represent the entire roadway.

The relationship between OSM ways and GeoBase segments is a many to many 
relationship.

The methods that I've come across for representing this in the OSM data model 
are

1) Split the OSM ways to the smallest common components (This is how we 
imported Fort McMurray, and seems to be the generally accepted solution to 
dealing with this type of thing in OSM today).

2) See http://wiki.openstreetmap.org/wiki/Relations/Proposed/Segmented_Tag
This proposed scheme would allow a relation to point to the start/end of
the portion way a osm way that the geobase uuid applies to.

3) Create a second ways that don't get rendered but shares the same nodes. 
You would then need to  associate these child ways to the parent through 
some method.  (I'm not a big fan of this)


 The script could be as simple as looking for intersections and dividing
 ways whenever it encounters one.  The end result would be a tremendous
 number of ways within Canada, I would be curious as to how many
 roadsegments are within GeoBase, and it would have to be rerun prior to
 any updates from GeoBase being applied to OSM to catch new user entered
 data, but it would match what GeoBase looks like.  Then running
 RoadMatcher against the results and have the pertinent data from GeoBase
 imported to the new OSM ways.

Ontario, BC, Alberta and The Yukon combined have about 1.1 million road 
segments in the NRN (those are the only datasets I have loaded).

 effected by it as opposed to a long way, or a section of it.  The other
 alternative is to get a better understanding of how to generate a script
 that will create relationships within longer ways and retain the long
 ways but still include the GeoBase NIDs for the appropriate sections

Modifying geobase2osm.py to merge adjoining ways if they share the same 
name, (and maybe # of lanes) would not be hard.  It could create the 
relation for Segmented ways as well.  However I wouldn't want to start bulk 
importing data that uses a tagging scheme that hasn't been approved where 
there is already a generally accepted method of doing this (splitting the 
ways)


 Richard Degelder



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

[Talk-ca] NRN Fort McMurray area data

[Steve Singer]

I have prepared some .osm files for the portion of the 074 NTS tileset that 
lies within Alberta.  This includes the Fort McMurray area. It is a small 
dataset since most of the tile lies outside of Alberta.

If the standalone detection worked properly we should be able to upload the 
.standalone and not create any duplicate ways (My inputs where based on the 
Jan 07 canada.osm dump).  People could the use the full in JOSM 074.osm file 
to find places where roads are still missing and manually add them in.

The questions I have for the group are:
1) What aspects of the tagging are we unhappy with.  These files differ from 
the svn geobase2osm in that they:

* Drop attribution from nodes (mentioned on the list)
* Add support for the is_in tag (Do we like the results of this)
* Road naming as I proposed in a previous email to the list

What other aspects of the tagging do we want to change?

2) Are we able to find a significant number of places where the standalone 
failed and will result in duplicate ways in OSM? This method will result in 
the import missing some roads but I can live with people manually 
finding+adding them. If others can't, then its time to speak up.

074.osm (All NRN roads)
http://www.mediafire.com/?zbqfkbgedzd

074.osm.standalone (Roads that are clearly standalone)
http://www.mediafire.com/?ymuznq2y2td

Result.jml (RoadMatcher output)
http://www.mediafire.com/?mynmuhn4ibv

Please hold off on hitting upload in JOSM on these files.



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

[Talk-ca] road names

[Steve Singer]

I want to talk about road names.

The NRN has the following fields for road names

nrn:left_OfficialStreetNameConcat
nrn:right_OfficialStreetNameConcat
nrn:routeNameEnglish1 (along with 2-4)
nrn:routeNameFrench1 (along with 2-4)

I have only downloaded BC, Alberta and the Yukon and also Ontario, but 
apparently we don't name our streets here :)

In all three cases we get instances where the OfficialStreetName differs 
from the route name.

Some examples:
  rtename1en |   datasetnam| l_stname_c
  Smiths Road   | Yukon Territory | Smith's Road
  Cousins Airstrip Road | Yukon Territory | Cousins Airfield Road
  Klondike Highway  | Yukon Territory | Front Street
  Hwy 22  | British Columbia | Columbia Avenue
  TransCanada Highway | Alberta  | 16 Highway

In the Yukon they seem to use the route name as a holder for a slightly 
different name.

In BC and Alberta they seem to almost always only use rtename as a highway 
designator.

If they are both defined I think we should take

right_OfficialStreetNameConcat=name
routeNameEnglish[1-4]=nat_name:en
routeNameFrench[1-4]=nat_name:fr

where we concat the multiple route names separated by ';'.
If the OfficialStreetName is - or None then we use the routeName1English, 
except in Quebec where we'd use the routeName1French=name

Or if anyone has a better idea put it forward.

I'd be happy with something that works 80% of the time, anyone can always 
manually edit the tagging of individual roads after the import.


Steve

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

Re: [Talk-ca] Geobase NRN import script

[Steve Singer]

On Thu, 1 Jan 2009, James Ewen wrote:

 Can you slice the GML file up into chunks? We could manually start the
 import process by manually defining areas where we want to start
 importing data. Areas chosen by users with little or no existing data.


The geobase2osm.py script lets you pass a bounds file (with the -b option). 
This will only include roads that pass through the bounds specified in the 
file.  So you can take the full provincial GML files but only generate .osm 
files for smaller chunks.

As Jason mentions in his other post, adjoining chunks will have duplicate 
ways.  I don't think it will be that difficult to eliminate these 
duplicates though.  We just need a script that searches for two OSM ways 
with the same geobase_nid that occupy the same space, and delete one of them 
+ merge in any adjoining ways.



 James
 VE6SRV


Steve



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

Re: [Talk-ca] Geobase Canadian Geo Boundaries Import

[Steve Singer]

On Sun, 28 Dec 2008, Michel Gilbert wrote:

 Hi all,

 I may have to remove the boundaries I have just uploaded. Is there a
 way to make a bulk removal ?

If you need to do a bulk removal one method that might 
work would be:

1. Open up a small area in JOSM that contains one of the provincial borders 
(with all these new nodes you might hit the object limit sooner than you 
think).  This will download the entire way not just the portion in your 
bounding box (which might be the cause of problems in the first place)

This will import/download the entire boundary, not just the portion in your 
download area.

2. Select the way in JOSM
3. Select your username in JOSM under the users table
4. Under the users menu Select Users Data

That should highlight all your data (which will include the boundary).  Then 
delete all the highlighted data (trashcan) and upload the change (I'd 
expect the upload to take a while).  Repeat for each of the boundaries you want 
to delete.







 I thought boundary layer was an easy one :(

Will we need to divide the boundaries into smaller ways of a few 
hundred-1000 nodes each?




 Michel



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

Re: [Talk-ca] OSM GeoBase import project.

[Steve Singer]

On Tue, 23 Dec 2008, James Ewen wrote:

 Okay, I have a really silly question to ask...


 I have seen posts from a few people that obviously have the skills and
 knowledge necessary to take GeoBase data, and manipulate it into a
 format that can then be imported into OSM. Are these people actively
 working with each other, and perhaps others with other skills to bring
 to the table somewhere in a dark office somewhere? Or perhaps is there
 no progress being made towards completion of this task?

I think some progress is being made, probably by individuals when they have 
spare cycles to devote to this.


 What I see that needs to be done is:

 Compile a list of datasets that are to be imported into OSM.
 Create a set of attributes that need to be attached to each dataset entry.
 Create scripts or whatever to convert the GeoBase data into OSM format.
 Get after making the import happen.

Review the wiki pages under 
http://wiki.openstreetmap.org/wiki/GeoBase_Import, some of this has been 
started.  Particularly for the political boundaries, NRN and NHN.  The 
attribute mappings could probably use some more attention.

Michel sent a link to a .osm file he generated with the poltical boundaries. 
I'm unsure what needs to happen to take this to the next step.

There is an initial geobase2osm script for the road network  in the OSM SVN 
repository, I've been working on a few enchancments to it but it still needs 
more work before we start importing samples and we have some open questions as 
to how we want to 
represent some things in OSM.



 There are lots of areas in Alberta that I am just itching to get after
 importing data into, where all that exists currently is a blank slate.
 If we had scripts or some other type of process that a dummy like
 myself could use, I'd be filling my boots getting GeoBase data merged
 into the OSM database. As long as the attributes imported are
 consistent across the nation, we should all be able to work towards
 the final goal, while still letting the smart cookies figure out the
 finer details, and getting issues like merging into developed areas
 dealt with. Why hold up the whole project because of a few minor
 issues?

 James
 VE6SRV



Steve



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

Re: [Talk-ca] GeoBase and OpenStreetMap

[Steve Singer]

On Wed, 17 Dec 2008, Dave Hansen wrote:

 There are several concerns here.  First, as you pointed out, is that we
 have virtually no control over what other users in OSM do.  There are no
 access controls or integrity constraints beyond some very simple ones.
 If we decided to strongly preserve the tiger TLIDs (or their GeoBase
 equivalent), I'm not even sure it would be possible without some serious
 changes to how OSM works.

You could have a monitoring script that looked at diffs and tried to detect 
some of these things and emailed out alerts.  The community could then 
fix (and educate users) as they happen.

 If you really want to track the GeoBase ways after they are imported,
 what about looking at the planet diffs?  You could keep a record of what
 happened to each object as it gets modified by users.  There would be no
 need to match up data because you would know how each piece got there.


What about using relations to store store the geobase id.  Tag each node in 
geobase segment way with a relation that contains the geobase id.  That way 
you can have multiple geobase segments map to a single OSM way.



 -- Dave


Steve



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

Re: [Talk-ca] GeoBase Import - Where we stand now

[Steve Singer]

On Sat, 6 Dec 2008, Steve Singer wrote:

 Do we have a handle on:


To attempt to answer my own question.

 a) How many tiles have 0 OSM roads (but do have at least 1 road in the
 geobase nrn)

It looks like 245 of the 250k (4 digit) NTS tiles have at least 1 'road' in 
OSM (see note 1).

I do not yet know how many NTS tiles have at least 1 road in geobase (I 
don't have all the data downloaded).


 b) How many tiles have OSM coverage similar to Tofino BC (or any your other
 examples from above) , and how much manual effort does it take someone in
 JOSM to manually fix up the duplicate ways following a OSM import.
 c) How many tiles (that have roads) are left over?


The Tofino BC is part of the 'Port Alberni'  250k tile 092F.  It has 103 
roads and is probably a good divider for discussion.

8 Tiles have more than 1000 roads in OSM 
(TORONTO,OTTAWA,QUEBEC,MONTREAL,KITCHENER,DETROIT,VANCOUVER)

40 tiles have more than 100 roads in  OSM.

105 tiles have 20 or more roads.

Breaking the analysis into the smaller 50k tiles shows that only 50 of the 
smaller tiles have more than 100 roads.



I think Dale pointed out that the NRN is segmented by province not NTS tile. 
This is true but a province to too large of an area to deal with as a 
single 'work unit'. The NTS tiling system seems like a reasonable way of 
breaking things up (geobase distributes the larger datasets like the hydro 
network by nts tile id).

Notes:
1. 'road' means anything that the osm2pgsql program adds to the '_roads' 
table and has a non-null highway attribute. 
2. This is based on recent (downloaded Dec06/08) canada.osm snapshot.

Steve



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