Re: [Talk-ca] Google Map Maker now in Canada

[G. Michael Carter]

Personally I only care about usage.   OSM isn't everywhere, neither is
google.   So for the areas I visit I'd love to have both just as accurate.

Michael

On Mon, Oct 24, 2011 at 10:36 AM, Connors, Bernie (SNB) <
bernie.conn...@snb.ca> wrote:

> Why would anyone contribute their local mapping knowledge to the closed
> system of a billion dollar company (Google) when they can support the free
> and open mapping system of OSM instead?
>
> ** **
>
> I did not post the message about Google Map Maker to this list to encourage
> contributions to Google Maps – just simply to alert OSM users to the news.
> 
>
> ** **
>
> Bernie.
>
> --
>
> *Bernie Connors, P.Eng*
>
> Service New Brunswick
>
> (506) 444-2077
>
> 45°56'25.21"N, 66°38'53.65"W
>
> www.snb.ca/geonb/
>
> ** **
>
> *From:* mikeycarter1...@gmail.com [mailto:mikeycarter1...@gmail.com] *On
> Behalf Of *G. Michael Carter
> *Sent:* Monday, 2011-10-24 11:25
> *To:* Connors, Bernie (SNB)
> *Cc:* Talk-CA OpenStreetMap
> *Subject:* Re: [Talk-ca] Google Map Maker now in Canada
>
> ** **
>
> Any idea how to upload GPS track log?   Also what's the policy of using OSM
> data?
>
> ** **
>
> Michael
>
> On Mon, Oct 24, 2011 at 10:00 AM, Connors, Bernie (SNB) <
> bernie.conn...@snb.ca> wrote:
>
>
> http://m.ctv.ca/topstories/20111024/google-canada-map-maker-request-111024.html#menu
> 
>
>  
>
> --
>
> *Bernie Connors, P.Eng*
>
> *Manager – Spatial Data Infrastructure*
>
> Land Information Secretariat
>
> Service New Brunswick
>
> Tel: 506-444-2077 Fax: 506-453-3898
>
> 45°56'25.21"N, 66°38'53.65"W
>
> bernie.conn...@snb.ca
>
> www.snb.ca/geonb/
>
>  
>
>  
>
>
> ___
> 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] Google Map Maker now in Canada

[G. Michael Carter]

Any idea how to upload GPS track log?   Also what's the policy of using OSM
data?

Michael

On Mon, Oct 24, 2011 at 10:00 AM, Connors, Bernie (SNB) <
bernie.conn...@snb.ca> wrote:

>
> http://m.ctv.ca/topstories/20111024/google-canada-map-maker-request-111024.html#menu
> 
>
> ** **
>
> --
>
> *Bernie Connors, P.Eng*
>
> *Manager – Spatial Data Infrastructure*
>
> Land Information Secretariat
>
> Service New Brunswick
>
> Tel: 506-444-2077 Fax: 506-453-3898
>
> 45°56'25.21"N, 66°38'53.65"W
>
> bernie.conn...@snb.ca
>
> www.snb.ca/geonb/
>
> ** **
>
> ** **
>
> ___
> 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] Any way to put a watch on an object?

[G. Michael Carter]

I finally got the Lake Ontario object reconstructed.
http://www.openstreetmap.org/browse/relation/1206310

If anyone starts deleting portions of it again well get the rendering
problems like we've been having.  (aka lakes disappearing and islands
sinking)   If I could watch the object for changes I could keep correcting
it as needed.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Weird Rendering issues.

[G. Michael Carter]

Never mind figured it out.
http://wiki.openstreetmap.org/wiki/Coastline_error_checker

There's gaps in the north-america coastline.  Since the lake ontario has
been converted back to coastline the rendering is going to be weeks... if
ever with the gaps.

Michael

On Mon, Sep 5, 2011 at 11:09 AM, G. Michael Carter wrote:

> http://www.openstreetmap.org/?lat=43.98355&lon=-77.74038&zoom=17&layers=M
>
>
> There seems to be a lot of weird rendering issues around Lake Ontario.  Any
> one have any ideas what the light green is?
>
> Michael
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Weird Rendering issues.

[G. Michael Carter]

http://www.openstreetmap.org/?lat=43.98355&lon=-77.74038&zoom=17&layers=M


There seems to be a lot of weird rendering issues around Lake Ontario.  Any
one have any ideas what the light green is?

Michael

-- 
*

G. Michael Carter*
 Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009
Google Talk: xmpp:mikeycarter1...@gmail.com

<http://livedvd.carterfamily.ca/><http://www.openstreetmap.org/?lat=43.9216&lon=-80.105&zoom=14&layers=B000FTF>
<http://www.openstreetmap.org/?lat=43.9216&lon=-80.105&zoom=14&layers=B000FTF>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Your new coastline

[G. Michael Carter]

I wish they'd updated the Bing high resolution images  In Orangeville
there's a new mall, but only one image (of three tiles) has the new mall,
the other has the cleared field from when they started.  I can only put in
half the buildings.

Any ideas on how often they update the high res?

On Fri, Sep 2, 2011 at 3:08 PM, Andrew MacKinnon wrote:

> On Thu, Sep 1, 2011 at 11:15 PM, James A. Treacy 
> wrote:
> > On Thu, Sep 01, 2011 at 10:30:34PM -0400, Andrew MacKinnon wrote:
> >> Given that this sort of work is time consuming it will take a while to
> >> finish. However, 99% of the work that requires importing coastlines
> >> from CanVec is done, and realigning coastlines using Bing is a lot
> >> less disruptive and less error-prone.
> >
> > I'm curious why you would trust the Bing imagery more than canvec. In
> > addition to not being very high resolution, I would think that Bing
> > would suffer from problems with registration (alignment of images to
> > lat/lon) which would have to be checked against ground readings. Of
> > course canvec should also be checked for accuracy with local readings.
> >
> > Further, my understanding is that much of the canvec data is generated
> > from local surveying, which uses high end GPS which are extremely
> > accurate.
> >
> > Locally (Kitchener-Waterloo) I have found that the canvec data is very
> > accurate and most imagery less so.
>
> I have been using the Bing imagery where high resolution imagery is
> available and Canvec where high resolution Bing imagery is not
> available. My impression is that for coastlines, tracing from Bing
> imagery is more accurate than the Canvec data.
>
> Keep in mind that some of the Canvec data is VERY out of date. While
> the road data in Canvec is fairly up to date, the rest of the Canvec
> data seems to be old (1990s, 1980s even?) Canvec data shows woods,
> buildings etc. which clearly haven't existed for many years, for
> example it often shows forests in areas where new subdivisions have
> been built recently, old industrial buildings which were torn down 10
> years ago and replaced with housing, long-ago abandoned rail spurs to
> industrial areas and long-demolished agricultural buildings. I would
> not trust anything except the roads layer in Canvec to be up to date.
>
> ___
> 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] Your new coastline

[G. Michael Carter]

Any eta on when you'll be finish with the lake Ontario coastline?

Sent from my iPhone

On 2011-09-01, at 12:19 AM, Andrew MacKinnon  wrote:

> On Mon, Aug 29, 2011 at 9:23 AM, G. Michael Carter
>  wrote:
>> Andrew,
>> In addition to the missing lakes and marshes documented on talk-ca here's
>> another if your keeping a list:
>> http://www.openstreetmap.org/?lat=43.98365&lon=-77.7393&zoom=17&layers=M
>> Also as another FYI you may have a gap somewhere in the coastline which
>> could be causing a lot of the rendering problems.
>> 
>> ie:
>>  http://www.openstreetmap.org/?lat=43.88528&lon=-78.67676&zoom=17&layers=M
>> I've tried refreshing it but it's just not seeing the changes you made.
>> really this marsh should be a separate entity cut off at lake Ontario.
>> Michael
> 
> I don't see any problems with the data in either of these cases, it's
> probably Mapnik not rerendering properly.
> 
> ___
> 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] Your new coastline

[G. Michael Carter]

Andrew,

In addition to the missing lakes and marshes documented on talk-ca here's
another if your keeping a list:

http://www.openstreetmap.org/?lat=43.98365&lon=-77.7393&zoom=17&layers=M

Also as another FYI you may have a gap somewhere in the coastline which
could be causing a lot of the rendering problems.

ie:
http://www.openstreetmap.org/?lat=43.88528&lon=-78.67676&zoom=17&layers=M

I've tried refreshing it but it's just not seeing the changes you made.
really this marsh should be a separate entity cut off at lake Ontario.

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

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

[G. Michael Carter]

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.

What I was doing was using canvec data to create a Canadian side water
object of the Lake Ontario, then changing the coastline side to a
multi-purpose line to reconnect the coastline.  Just needed to finish it
before I could connect it.  (posted that to the talk-ca list a while ago)

Problem with coastlines on internal lakes, is to render the great lakes you
need to pull in all of north-america.   GPS can't render partial data.
 (Unless you know another way)

I guess since my objects are being trashed the only thing I can do is pull
all of North America to render these lakes.  Guess this is they way of OSM,
you can have your project in progress trashed because someone has a
different view.  Oh well.

Andrew,

Any projection to when you will be completely finished your work?   Now that
I have to pull all of north america I want to wait till your done before I
start the 18G transfer.


Michael

On Sun, Aug 28, 2011 at 8:02 PM, Richard Weait  wrote:

> On Sun, Aug 28, 2011 at 11:36 AM, G. Michael Carter
>  wrote:
> > I just loaded the latest data for Ontario.
> > I noticed my Lake ontario object is missing.  Is there a reason or was it
> > just an oversight?
>
> Looking for this one?
>
> http://www.openstreetmap.org/browse/relation/1205143
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Lake Ontario Missing...

[G. Michael Carter]

I just loaded the latest data for Ontario.

I noticed my Lake ontario object is missing.  Is there a reason or was it
just an oversight?
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Update on updating the Lake Huron shoreline

[G. Michael Carter]

What I did with lake superior is used the canvec data to build the big lake
superior object.  The multi-polygon become natural=water.   then converted
the entire line that was the shore to natural=coastline and connect it to
the existing coastline out side the object.   That way if you import the
data into a GPS the lake object for canada shows up, but the is an existing
coastline as well (which the US side uses a coastline)

Personally I like the idea of having the lake object that way you can pull
it as one object.

Michael

On Mon, Aug 22, 2011 at 2:03 PM, Daniel Begin  wrote:

> Hi all,
>
> I have been imported Canvec data around US-QC-ON border and I'm having a
> similar question.  When should we use Canvec data as is (natural=water) and
> when should we transform it into natural=coastline?
>
> Using natural=coastline on US border (to match tagging with the US portion)
> seems fine to me but when do we switch to the other representation?
>
> Does someone have a proposition?
>
> Daniel
>
> -Original Message-
> From: James A. Treacy [mailto:tre...@debian.org]
> Sent: August-09-11 14:32
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Update on updating the Lake Huron shoreline
>
> Hello,
> Another update on the conversion of the Great Lakes shoreline plus
> one question.
>
> After something like 10,000 islands, the conversion of the Canadian
> shore of Lake Huron (including Georgian Bay) to use the canvec data
> is completed! That is a LOT of islands. Given the magnitude of the
> task, few changes were made to the land side of things. That's not
> quite true as all the islands had all features added - including
> Manitoulin Island.
>
> For the areas that have been rendered it looks much better. It could
> be a few weeks before the remainder of the shoreline is updated.
>
> I have started moving down the St Clair River (connecting Lake Huron
> and Lake Erie) and have a question:
>
> Is there any preferred method to decide where to stop using coastline
> and to start using natural=water? There are some channels that cut off
> a large part of the mainland in NE Lake St. Clair which could easily
> be used as the shoreline. That would be a huge change from the current
> shoreline though. Additionally, the route of the current shoreline
> would be time consuming to maintain as it would involve cutting up a
> number of areas that canvec renders as water. I'd think the best route
> would be to use the definition of the shoreline as defined by some
> official governmental body, if such a thing exists.
>
> Any suggestions? Even an answer of 'just do what is convenient' would
> be helpful.
>
> --
> James (Jay) Treacy
> tre...@debian.org
>
> ___
> 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
>



-- 
*

G. Michael Carter*
 Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009
Google Talk: xmpp:mikeycarter1...@gmail.com

<http://livedvd.carterfamily.ca/><http://www.openstreetmap.org/?lat=43.9216&lon=-80.105&zoom=14&layers=B000FTF>
<http://www.openstreetmap.org/?lat=43.9216&lon=-80.105&zoom=14&layers=B000FTF>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Ping John Whelan?

[G. Michael Carter]

OK curiosity is getting the better of me.   What's the issue?  Why the
sudden panic attack to remove data?  (I must probably missed that part :)

What's wrong with CT/ODbL?

On Tue, Jun 7, 2011 at 1:24 PM, Richard Weait  wrote:

> On Tue, Jun 7, 2011 at 12:24 PM, john whelan 
> wrote:
> > I would be extremely happy to see all my edits removed.
>
> Earlier you said that you were happy to have your surveyed data
> included in OSM under CT/ODbL, but you wanted Canvec data you uploaded
> removed.
>
> Now you say, "I would be extremely happy to see all my edits removed. "
>
> Which is it?
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Lake Simcoe - two versions?

[G. Michael Carter]

Barrie area was probably my import before we had OSM files from CanVec.
Can't remember.  I think the duplicate is because at the time I couldn't get
an answer on what to do with the coastline.  But since the lake is self
contained it can probably be deleted.

Michael

On Mon, May 30, 2011 at 4:33 PM, Frank Steggink wrote:

> On 11-05-30 09:15 PM, Me (Gmail) wrote:
>
>> I've been working on improving the Barrie, Ontario area, and I'm
>> trying to figure out what is going on with/what to do about Lake
>> Simcoe.
>>
>> There are multiple CanVec-imported ways that together make up a fairly
>> detailed, accurate representation of the lake. A single low-detail way
>> [1] is overlapping these, and obscures the accurate detail in many
>> places when rendered [2].
>>
>> [1]: http://www.openstreetmap.org/browse/way/4997263
>> [2]: http://dl.dropbox.com/u/2398828/lake-simcoe-josm.png
>>
>> Not having much experience dealing with large or tiled objects in OSM,
>> my question is if the low-resolution object is serving a purpose, and
>> whether I should bother editing it so as to not overlap with the
>> high-detail version, or whether it can just be deleted.
>>
>>  Hi AJ,
>
> The Canvec version is clearly better, so the lowres version can be deleted.
> It was probably one of the features being traced when only Landsat imagery
> was available. In my opinion this cleaning up should have been done during
> the import of the Canvec sheet. Otherwise this import gets more
> characteristics of a "bad import" (by leaving duplicate features), which we
> should prevent. (Note that there are also some people who think that user
> traced features are always better than imported features, but in this case
> the difference is evident, and nobody has bothered yet to trace the
> shoreline from the Bing imagery.)
>
> What might have caused this is that Lake Simcoe overlaps several sheets, so
> it can't be deleted at once. Wat I usually do is to cut the part of the
> coastline which is overlapping the sheet being imported, and connect the
> existing coastline to the new one. An example of this can be seen in the
> southeast part of Lac Saint-Jean in Québec: [1]. This is also how I've dealt
> with the Saguenay river, and also with the St. Lawrence coastline. This can
> best be done asap, because you never know for sure when you continue with
> the rest. It is a bit more work, but in my opinion it's much better than
> confusing or even annoying others.
>
> Frank
>
> [1] http://osm.org/go/cLD8wZR--
>
>
> ___
> 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] Great Lakes shoreline

[G. Michael Carter]

My suggestion on the coastline.  Connect both the canvec and existing
together at some point.  Leave it for a few days.  Then delete the old one.

That way there's always a connected coastline.   Especially if the coastline
is one of the great lakes.  It also handles the case I ran into.   I
finished a project and moved on, then someone wiped out part of my changes
with an update (they grabbed data days before my updates) this created a
disconnected coastline.

Michael

On Wed, Apr 20, 2011 at 12:29 PM, James A. Treacy  wrote:

> Hello,
> I have been adding canvec data for the last part of the Bruce
> Peninsula and noticed that the existing shoreline is quite different
> than that given by the canvec data. The source for the existing
> coastline is r_coastlines and I have no idea who/what that is.
> I don't know which is more accurate but the canvec coastline matches
> much better with the land features.
>
> Should the existing coastline be left alone or should it be switched
> over?
>
> --
> James (Jay) Treacy
> tre...@debian.org
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>



-- 
*

G. Michael Carter*
 Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009
Google Talk: xmpp:mikeycarter1...@gmail.com

<http://livedvd.carterfamily.ca/><http://www.openstreetmap.org/?lat=43.9216&lon=-80.105&zoom=14&layers=B000FTF>
<http://www.openstreetmap.org/?lat=43.9216&lon=-80.105&zoom=14&layers=B000FTF>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec Contour Lines

[G. Michael Carter]

 Wasn't sure if I came across right.  I was thinking as separate 
files.   Contour lines are not in the OSM, told they will never in 
there, at one point.


Michael

On 29/09/10 11:48 AM, Bégin, Daniel wrote:

Hi Michael,

I understand your need and I did some tests. On average, adding contours means 
twice the amount of disk space/processing time, generates up to 10 times more 
.osm files.

I'll keep the process as it is now.

Daniel

-Original Message-
From: talk-ca-boun...@openstreetmap.org 
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter
Sent: September 27, 2010 17:26
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] CanVec Contour Lines


   Would it be possible to get the Contour Lines as OSM files?   I import
them into my GPS from the shp files.   Just though it would be nice to
have without the manual conversion step I do.

If not, no big deal.   Just thought I'd ask.

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

[Talk-ca] CanVec Contour Lines

[G. Michael Carter]

 Would it be possible to get the Contour Lines as OSM files?   I import 
them into my GPS from the shp files.   Just though it would be nice to 
have without the manual conversion step I do.


If not, no big deal.   Just thought I'd ask.

Michael

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

[Talk-ca] Any one on Rogers network?

[G. Michael Carter]

 For the last month b.tile.openstreetmap.org times out and I get "tile 
coming soon" (aka 404 errors) ... and not the only rogers problem I have 
I might add...


When I access it from acanac or bell or rogers 3g network it's fine.

Two questions:

1.  Any one on rogers?  and if so can you send me your traceroute 
b.tile.openstreetmap.org (linux) or tracert b.tile.openstreetmap.org 
(windows)


2.  Is there a black list on the osm servers that could be causing this?

Thanks,
Michael


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

[Talk-ca] natural=land

[G. Michael Carter]

 Is there any case where we'd be using natural=land any more?

I've been thinking of taking the osm data in my db and creating a list 
of common errors.   Something like http://keepright.ipax.at 
 but as just a check list.   One thing I'm 
going to scan for is identical ways...




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

Re: [Talk-ca] Sinking islands...

[G. Michael Carter]

  
  
I'm fine with making the island name a point.   It would show up in
POI applications.  

On 23/09/10 11:28 AM, Bégin, Daniel wrote:

  
  
  Cool, 
   
  So, what should be
done for the next release?
  - Keep the
natural=land areas - everybody will have to merge each
island to get the proper rendering;
  - Transform the
natural=land areas into points - no merging necessary, no
name lost;
  - Remove the
natural=land areas - name will be lost for next release (1);
   
  I'm inclided to
implement the second proposition - Easier for me and for
most of the contributors;
   
  Daniel
   
   
  1- The name should
be found in both Canvec Island and Named feature
(natural=land areas and place=island points) within the next
year.
  
  

    From: G. Michael Carter
  [mailto:mikeycarter1...@gmail.com] On Behalf Of G.
      Michael Carter
  Sent: September 23, 2010 10:48
  To: Bégin, Daniel
  Cc: Talk-CA OpenStreetMap
  Subject: Re: [Talk-ca] Sinking islands...

  
  I've been taking all three objects and merging them.  So the inner
  is natural=wood, with name.
  
  http://www.openstreetmap.org/?lat=45.45968&lon=-80.42647&zoom=16&layers=M
  
  
  Seems to be rendering ok.   Childs and Osawa are examples.
  
  On 23/09/10 10:38 AM, Bégin, Daniel wrote:
  

You are right :-(
 
Two solutions are
  possible for the next release...
- Convert
  natural=land area into point feature - the easy solution
  to always keep the name available;
- Associate the
  name to the inner component - If it renders properly. 
 
The second one is
  much more complex (from my side). Can someone try it and
  send me the conclusion? 
 
Daniel


       From:
    G. Michael Carter [mailto:mikeycarter1...@gmail.com]
        On Behalf Of G. Michael Carter
Sent: September 23, 2010 10:14
To: Bégin, Daniel
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Sinking islands...
  

I notice for islands with names the name tag is on the
natural=land.   

On 23/09/10 10:00 AM, Bégin, Daniel wrote:

  Bonjour Michael,

2010-08-16 11:54 [Talk-ca] Canvec.osm Product - Running!
I wrote  "natural=land  area features are a duplicate of natural=water inner polygon. It will be removed for the next release.  Point features will still be there."  

I understand that natural=land has priority in the rendering. Rendering will then "move" any overlapping features "under" the natural=land feature. It means you are better remove natural=land area before importing.

The standard case for an island is 
- an inner component of a relation type=multipolygon : natural=water
- a polygon : natural=land
- a polygon : natural=wood

Remove the polygon natural=land and the polygon natural=wood will render properly  in the hole created by the inner component of the natural=water multipolygon.

Daniel

-Original Message-
From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter
Sent: September 23, 2010 09:09
To: Talk-CA OpenStreetMap; talk...@openstreetmap.org
Subject: [Talk-ca] Sinking islands...


  I was importing data in the Georgian Bay area and I noticed 
something.   If an island is natural=land it renders in mapnik as white, 
regardless of the outer multipolygon.   if you have natrual=wood or 
possibly others, it sinks if it's not role=inner.

This is at least what I've observed so far.   It's rather hard to figure 
out when the mapnik tiles get cached and don't refresh in a timely fashion. :-)





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

    
  
  



-- 
  
G. Michael Carter
  
  
Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M:
1-519-215-1869 | F: 1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com

  
  
  

  

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

Re: [Talk-ca] Missing islands and coastline

[G. Michael Carter]

 The mix of natual=water and natural=coastline is because their dual 
objects.   The natural=coastline is needed as the great lakes (as far as 
I know) is connected to the ocean.  So deleting the coastline would 
delete portions of the Atlantic Ocean.


What I'm doing is enclosing the Canadian side of the great lakes, 
(object http://www.openstreetmap.org/browse/relation/1120169  (which 
needs to be loaded in sections in JOSM)


My reasons:
1.  Coastline's need to be complete to render properly.  So if your 
loading Toronto island (Lake Ontario) into a system, you have to pull 
half the worlds oceans to get it to render properly... as with 
incomplete data a rendering engine can't till which side contains the 
water.   Having a enclosed relation allows you to pull just that area.
2.  It's currently impossible to tell if a coastline object is fully 
enclosed inside JOSM editing.  But if you have a enclosed relation 
object (with type natural=water) where just one side is the coastline.  
You can easily tell by downloading the relation (aka 1120169)

3.  Naming.   Can't name a sting of coastline as easy as a single relation.

As for coastlines inland (like Lake Simcoe) make absolutely no sense to 
me as it's not a coastline.  So my thought, if you have a natural=water 
object that more accurately represents the body of water... use it to 
replace the interior coastline.


But that's just my take...


On 22/09/10 12:46 PM, Nakor wrote:

Michael,

The relation in question is 
http://www.openstreetmap.org/browse/relation/1124369 but hit a wall 
here. I cannot modify it (both Potlatch and JOSM time out). Isle 
Royale (which was my initial concern) is still missing on a couple 
zoom levels.


Before I continue trying to fix this it seems there are a mix of 
natural=water and natural=coastline for the Great Lakes. I'd like to 
have this consistent over the Great Lakes but am not sure which one to 
use. Please comment which one would be better/worse and why?


  Thanks,

N.



On 9/20/2010 10:20 AM, G. Michael Carter wrote:
 It was brought to my attention there was some problems in Lake 
Superior area, but the problems seem to be all over the great 
lakes.   There's a user, who's name I don't have handy, creating 
massive relationship objects of the great lakes.  I think this might 
be sinking a lot of the islands.   The island objects were last 
modified by this user in the cases I checked.


However, if you refresh the mapnik (aka /dirty) the tiles everything 
seems to be refreshing ok.   Just wanted to let people know.If 
you find some area underwater refresh the tiles, before investigating.


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




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

Re: [Talk-ca] Sinking islands...

[G. Michael Carter]

 I've been taking all three objects and merging them.  So the inner is 
natural=wood, with name.


http://www.openstreetmap.org/?lat=45.45968&lon=-80.42647&zoom=16&layers=M 
<http://www.openstreetmap.org/?lat=45.45968&lon=-80.42647&zoom=16&layers=M>


Seems to be rendering ok.   Childs and Osawa are examples.

On 23/09/10 10:38 AM, Bégin, Daniel wrote:

You are right :-(
Two solutions are possible for the next release...
- Convert natural=land area into point feature - the easy solution to 
always keep the name available;

- Associate the name to the inner component - If it renders properly.
The second one is much more complex (from my side). Can someone try it 
and send me the conclusion?

Daniel

------------
*From:* G. Michael Carter [mailto:mikeycarter1...@gmail.com] *On 
Behalf Of *G. Michael Carter

*Sent:* September 23, 2010 10:14
*To:* Bégin, Daniel
*Cc:* Talk-CA OpenStreetMap
*Subject:* Re: [Talk-ca] Sinking islands...

I notice for islands with names the name tag is on the natural=land.

On 23/09/10 10:00 AM, Bégin, Daniel wrote:

Bonjour Michael,

2010-08-16 11:54 [Talk-ca] Canvec.osm Product - Running!
I wrote  "natural=land  area features are a duplicate of natural=water inner 
polygon. It will be removed for the next release.  Point features will still be 
there."

I understand that natural=land has priority in the rendering. Rendering will then "move" 
any overlapping features "under" the natural=land feature. It means you are better remove 
natural=land area before importing.

The standard case for an island is
- an inner component of a relation type=multipolygon : natural=water
- a polygon : natural=land
- a polygon : natural=wood

Remove the polygon natural=land and the polygon natural=wood will render 
properly  in the hole created by the inner component of the natural=water 
multipolygon.

Daniel

-Original Message-
From:talk-ca-boun...@openstreetmap.org  
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter
Sent: September 23, 2010 09:09
To: Talk-CA OpenStreetMap;talk...@openstreetmap.org
Subject: [Talk-ca] Sinking islands...


   I was importing data in the Georgian Bay area and I noticed
something.   If an island is natural=land it renders in mapnik as white,
regardless of the outer multipolygon.   if you have natrual=wood or
possibly others, it sinks if it's not role=inner.

This is at least what I've observed so far.   It's rather hard to figure
out when the mapnik tiles get cached and don't refresh in a timely fashion. :-)





___
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] Sinking islands...

[G. Michael Carter]

  
  
I notice for islands with names the name tag is on the
natural=land.   

On 23/09/10 10:00 AM, Bégin, Daniel wrote:

  Bonjour Michael,

2010-08-16 11:54 [Talk-ca] Canvec.osm Product - Running!
I wrote  "natural=land  area features are a duplicate of natural=water inner polygon. It will be removed for the next release.  Point features will still be there."  

I understand that natural=land has priority in the rendering. Rendering will then "move" any overlapping features "under" the natural=land feature. It means you are better remove natural=land area before importing.

The standard case for an island is 
- an inner component of a relation type=multipolygon : natural=water
- a polygon : natural=land
- a polygon : natural=wood

Remove the polygon natural=land and the polygon natural=wood will render properly  in the hole created by the inner component of the natural=water multipolygon.

Daniel

-Original Message-
From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter
Sent: September 23, 2010 09:09
To: Talk-CA OpenStreetMap; talk...@openstreetmap.org
Subject: [Talk-ca] Sinking islands...


  I was importing data in the Georgian Bay area and I noticed 
something.   If an island is natural=land it renders in mapnik as white, 
regardless of the outer multipolygon.   if you have natrual=wood or 
possibly others, it sinks if it's not role=inner.

This is at least what I've observed so far.   It's rather hard to figure 
out when the mapnik tiles get cached and don't refresh in a timely fashion. :-)





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




-- 
  
G. Michael Carter
  
  
Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M:
1-519-215-1869 | F: 1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com

  
  
  

  

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

Re: [Talk-ca] Sinking islands...

[G. Michael Carter]

  
  
In the cases where we have all three and they are identical.  Seems
better to have the three merged.   In any case good to know.  I'll
start removing them on import.

On 23/09/10 10:00 AM, Bégin, Daniel wrote:

  Bonjour Michael,

2010-08-16 11:54 [Talk-ca] Canvec.osm Product - Running!
I wrote  "natural=land  area features are a duplicate of natural=water inner polygon. It will be removed for the next release.  Point features will still be there."  

I understand that natural=land has priority in the rendering. Rendering will then "move" any overlapping features "under" the natural=land feature. It means you are better remove natural=land area before importing.

The standard case for an island is 
- an inner component of a relation type=multipolygon : natural=water
- a polygon : natural=land
- a polygon : natural=wood

Remove the polygon natural=land and the polygon natural=wood will render properly  in the hole created by the inner component of the natural=water multipolygon.

Daniel

-Original Message-
From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter
Sent: September 23, 2010 09:09
To: Talk-CA OpenStreetMap; talk...@openstreetmap.org
Subject: [Talk-ca] Sinking islands...


  I was importing data in the Georgian Bay area and I noticed 
something.   If an island is natural=land it renders in mapnik as white, 
regardless of the outer multipolygon.   if you have natrual=wood or 
possibly others, it sinks if it's not role=inner.

This is at least what I've observed so far.   It's rather hard to figure 
out when the mapnik tiles get cached and don't refresh in a timely fashion. :-)





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




-- 
  
G. Michael Carter
  
  
Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M:
1-519-215-1869 | F: 1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com

  
  
  

  

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

[Talk-ca] Sinking islands...

[G. Michael Carter]

 I was importing data in the Georgian Bay area and I noticed 
something.   If an island is natural=land it renders in mapnik as white, 
regardless of the outer multipolygon.   if you have natrual=wood or 
possibly others, it sinks if it's not role=inner.


This is at least what I've observed so far.   It's rather hard to figure 
out when the mapnik tiles get cached and don't refresh in a timely 
fashion. :-)






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

Re: [Talk-ca] Getting my edits to show up in Canvec Activity?

[G. Michael Carter]

 The way my system identifies which grid changes are in, is based on an 
imported text file, and postgresql's spatial engine.


Cache.txt which contains this sort of thing:

030L05.osm   -8042.4244862 
-79.803944142.5
030L11.osm   -79.5  42.6160398 
-79.144986342.75
030L12.osm   -8042.5   
-79.5  42.75


Which is file name, minlon, minlat, maxlon, maxlat

I'm NOT prepared to download all of Canada's Canvec data to get these 
borders.  The MB tiles in there are only there because I downloaded all 
of Ontario and those tiles are right on the border.


However, if you can send me a file in this format, I'd be happy to add 
it to the text file and import.


This is how I build that file:  ($x being the filename)
  export maxlat=$(cat $x | grep "lat=" | awk -Flat=\" {'print $2'} 
| awk -F\" {'print $1'} | sort | tail -1)
  export minlat=$(cat $x | grep "lat=" | awk -Flat=\" {'print $2'} 
| awk -F\" {'print $1'} | sort | head -1)
  export maxlon=$(cat $x | grep "lon=" | awk -Flon=\" {'print $2'} 
| awk -F\" {'print $1'} | sort | head -1)
  export minlon=$(cat $x | grep "lon=" | awk -Flon=\" {'print $2'} 
| awk -F\" {'print $1'} | sort | tail -1)


  printf "%-20s %-22s %-22s %-22s %-22s\n" >> Cache.txt ${Name}.osm 
$minlon $minlat $maxlon $maxlat



Michael

On 22/09/10 09:11 AM, Tyler Gunn wrote:

So what's the trick to getting edits to link up properly in the Canvec
activity chart?
http://osm.carterfamily.ca/canvec-activity.cgi

I've thusfar ONLY managed to get a small fraction of my edits to show up
linked out by tile rather than just being accumulated in my big-'ole blob
of edits:
  MB   | Tygunn | 2010-09-21 22:14:13 | 61665 |
0 | Active

I typically set my changeset comments to something like:
Canvec 062J02.1.osm

Just wondering what pattern I should use?

Thanks!
Tyler


--
Tyler Gunn
ty...@egunn.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

[Talk-ca] Missing islands and coastline

[G. Michael Carter]

 It was brought to my attention there was some problems in Lake 
Superior area, but the problems seem to be all over the great lakes.   
There's a user, who's name I don't have handy, creating massive 
relationship objects of the great lakes.  I think this might be sinking 
a lot of the islands.   The island objects were last modified by this 
user in the cases I checked.


However, if you refresh the mapnik (aka /dirty) the tiles everything 
seems to be refreshing ok.   Just wanted to let people know.If you 
find some area underwater refresh the tiles, before investigating.


Michael



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

Re: [Talk-ca] Deleted nodes.

[G. Michael Carter]

 I tried that script and had a huge mess.  Seems that Rogers Canada 
doesn't like OSM data, or me... not sure which yet.


It kept aborting due to timeout issue.

On 06/09/10 12:45 PM, Frank Steggink wrote:

Hi Michael,

You might want to look at upload.py [1]. This is a family of scripts 
related to OSM uploads and other processing. One of the benefits is 
that with it you can "sort" the data, so that ways and relations are 
uploaded immediately after the nodes are uploaded. This will prevent 
large amounts of unconnected nodes. As you know, JOSM first uploads 
all nodes, then all ways, and only then the relations.


If only nodes are missing, then you could try to upload another time. 
If you've already ended up with duplicate ways, etc. then you can try 
to see if they are cleaned up by validating the area in JOSM, select 
"Duplicate ways" in the Errors branch, then then fix. For some reason 
this doesn't work all the time...


Regarding those edits from magellan and the like, I've been hit with 
them sometimes as well (not with Canvec, but with 3dShapes in the 
Netherlands). It is very annoying. Just send them a PM that they 
should not clean up recent data, say anything which was uploaded less 
than a few days ago.


HTH,

Frank

[1] http://wiki.openstreetmap.org/wiki/Upload.py


On 10-09-06 04:44 PM, G. Michael Carter wrote:
I just it a rather frustrating scenario.   I was uploading a large 
set of data into the Thunder Bay area.   My network connection died 
in the middle.  (and didn't notice for a day)   No big deal, I just 
restarted the upload as it had been saving changes in the new JOSM.


However, what I didn't realize is magellan 
<http://www.openstreetmap.org/user/magellan> had gone in and started 
deleting any orphaned nodes from the now closed first change set.  So 
I have this big batch that I can't finish the upload as magellan has 
deleted all required nodes.


I've asked magellan if they could refrain from deleting objects in 
that area so I can fix the batch... just wanted people to be aware if 
there deleting in an area.   I'm guessing magellan saw the 50,000 
orphaned or duplicate nodes and did a clean up while my batches were 
still processing.   Problem is if your uploading and it's going to 
take multiple change sets the first set contains all the new nodes. 
(thus creating duplicates and orphans)  The second or third changeset 
has the ways, and relations.





___
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] Deleted nodes.

[G. Michael Carter]

 I just it a rather frustrating scenario.   I was uploading a large set 
of data into the Thunder Bay area.   My network connection died in the 
middle.  (and didn't notice for a day)   No big deal, I just restarted 
the upload as it had been saving changes in the new JOSM.


However, what I didn't realize is magellan 
 had gone in and started 
deleting any orphaned nodes from the now closed first change set.  So I 
have this big batch that I can't finish the upload as magellan has 
deleted all required nodes.


I've asked magellan if they could refrain from deleting objects in that 
area so I can fix the batch... just wanted people to be aware if there 
deleting in an area.   I'm guessing magellan saw the 50,000 orphaned or 
duplicate nodes and did a clean up while my batches were still 
processing.   Problem is if your uploading and it's going to take 
multiple change sets the first set contains all the new nodes. (thus 
creating duplicates and orphans)  The second or third changeset has the 
ways, and relations.




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

Re: [Talk-ca] Merging huge wooded areas?

[G. Michael Carter]

  
  
On another note the JOSM has a bug when merging two
multi-polygons.   I made the Canadian side of Lake Superior one
object, but I did it manually.    That is removed the lines that I
didn't need then selected all the objects of one multi-polygon then
added them to the second.  Then removing the first multi-polygon.

The wooded area in northern Ontario is one object spanning all of
northern Ontario.  So glad to here people don't mind the squares.   :-) 

Michael

On 02/09/10 09:08 AM, Bégin, Daniel wrote:

  Bonjour Tyler and all,

>From my own experience, I would strongly recommend not to merge large adjacent wooded (or anything else) areas. Furthermore, If I remember well, Frank Steggink tried the same and he decided to keep distinct relations - no merging. 

One of the reasons behind Canvec data tiling was editing tools abilities to deal with large polygon - and often complex relations.

Even our own systems have sometime hard time to deal with it!

Cheers,

Daniel

-Original Message-
From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Tyler Gunn
Sent: 2 septembre 2010 07:13
To: Talk-Ca http://www.openstreetmap.org/?lat=51.599&lon=-101.054&zoom=10&layers=M

It literally spans over an entire NTS tile (062N*).  I tried (as much as
possible) to ensure all outer/inner members of the wooded area are part of a single relation, but in retrospect that wasn't the right approach as you can still see the lines between the NTS sub-tiles.

So I'm thinking in this situation what I really need to do (once the entire extent of this wooded area has been imported) is download the entire area accompanied by the woods, and use the JOIN command in JOSM to merge the smaller wooded areas into one big massive one.  The end result would be one HUGE way that traces the entire outside of the wooded area.  All of the inside "divisions" between the tiles would be eliminated, and the end result would be a huge outer way and lots of inner ways.  I could then just split up the huge outer way as necessary to make sure no one part of the way is longer than 2000 nodes.

Does this sound reasonable?  Or am I over-complicating it?

Thanks!
Tyler

--
--
Tyler Gunn
ty...@egunn.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

    


-- 
  
G. Michael Carter
  
  
Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M:
1-519-215-1869 | F: 1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com

  
  
  

  

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

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

[G. Michael Carter]

>From an observer perspective.  In the areas I've entered CanVec v6 seems the 
>next version of GeoBase.A lot of roads are the similar but CanVect has a 
>lot more detailed points than the currently imported GeoBase.   Ie geobase 
>import has a winding roads as a set of inverted triangles were CanVec has 
>rounded edges.

But that's just the areas I've done

As for the official difference, I'll wait too for that response.

Sent from my iPhone

On 2010-08-20, at 7:52 PM, 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

Re: [Talk-ca] editing a canvect building question

[G. Michael Carter]

 Would it be possible to get a text file like this:



030L05.osm   -8042.4244862 
-79.803944142.5
030L11.osm   -79.5  42.6160398 
-79.144986342.75


Where the columns are GridName, MinLon, MinLat, MaxLon, MaxLat

Michael

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

Re: [Talk-ca] editing a canvect building question

[G. Michael Carter]

 My logic... if it's a new building, it's a new object so the tag 
references can go.   As for delete or modify... the end result, we want 
accurate objects, so in my opinion do what ever is easier.



On 18/08/10 01:57 PM, Louis-Marius Gendreau wrote:
Hi a building here 
 
is wrong.  Much of it has been destroyed and it was split in two in 
the process.  As it was imported from Canvect, I am wondering how to 
best adress this.  Delete and recreate? Change into one smaller 
building and keep all canvect reference tags on it and then create a 
new buildling for the other part? Other?




--
Louis-Marius Gendreau


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

Re: [Talk-ca] Hiding an object

[G. Michael Carter]

 Garmin format is unsupported and I think hell will freeze over before 
Garmin makes their GPSmap 60Cx opensource supported.


However, the more I play with this... I'm thinking of dropping the addr 
tags all together.   Provincial Park roads usually don't have names, so 
the address tags are making less and less sense.   The campsite numbers 
might better be served as POIs.   Routing still works if you select a 
POI, on any system I know.


The only issue is the rendering.  Some campgrounds pack in the sites so 
you could have 800+ POI close together (in some areas)


New question:  is there a way to specify it to render at only extreme 
zoom?   (ie I noticed the drinking water POI objects are like that)


Mikey



On 17/08/10 05:38 PM, Adam Dunn wrote:
This really sounds like a "mapping for the renderer" situation (in 
this case the renderer would be Garmin). This is generally 
discouraged. You have the address information (in the Karlsruhe 
schema), but the Garmin converter doesn't support it, so you are 
adding in extra tags to get better Garmin support. You should be 
trying to get a really good map database that is agnostic to render 
engines (be they Mapnik, osmarender, Garmin, or TomTom). It is up to 
the render engine/converter to improve how it handles the (supposedly) 
correct database.


Having said that, check out 
http://wiki.openstreetmap.org/wiki/Key:osmarender:render


Adam

On Tue, Aug 17, 2010 at 2:15 PM, G. Michael Carter 
mailto:mi...@carterfamily.ca>> wrote:


 Is there a tag to stop mapnik and other rendering engines from
rendering an object?

My idea for adding campsite numbers hit a brick wall.  Seems the
reverse engineering of Garmin doesn't support house numbers.   So
I'm thinking of creating a dual purpose object:

addr:city=Rock Point Provincial Park
addr:housenumber=56
addr:street=Campsite Roads

name=Rock Point Campsite: 56(still working on the name)
tourism=camp_site (reason is so it shows up on garmin devices
as Lodging)

(and possibly other tags still working this out.)


On JOSM it renders all the campsite numbers as tent objects.  I
think this might be very distracting on a map.  So I want to hide
them from site.  But still be there for searching purposes.

___
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto: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] Hiding an object

[G. Michael Carter]

 Is there a tag to stop mapnik and other rendering engines from 
rendering an object?


My idea for adding campsite numbers hit a brick wall.  Seems the reverse 
engineering of Garmin doesn't support house numbers.   So I'm thinking 
of creating a dual purpose object:


addr:city=Rock Point Provincial Park
addr:housenumber=56
addr:street=Campsite Roads

name=Rock Point Campsite: 56(still working on the name)
tourism=camp_site (reason is so it shows up on garmin devices as 
Lodging)


(and possibly other tags still working this out.)


On JOSM it renders all the campsite numbers as tent objects.  I think 
this might be very distracting on a map.  So I want to hide them from 
site.  But still be there for searching purposes.


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

[Talk-ca] Need Advice on Campsite numbers

[G. Michael Carter]

http://www.openstreetmap.org/browse/changeset/5500386

This change set is my first attempt at adding campsite numbers to a camp
ground.Thought I'd enter a few in and see how the down stream systems
react, see if I get desired effect.

The idea here:

1.  When loading data into my garmin GPS I can use the address search
feature to query Rock Point Provincial Park, house number (aka site number)
78.  Then the GPS will route my right to my site.

2.  http://maps.cloudmade.com/#  When doing routing by walking, biking, or
car.  You can program a route right to your site number.


So my questions:

1.  Do I need the addr:interpolation since I need to add a node for each
campsite.  (especially since the campsites are not always odd/even side or
even in order.)

2.  How do I label the addr:street , and
addr:city?
   City as "Rock Point Provincial Park"?  what about street name?  Park
roads are service roads with no names.   What about the camp ground name?
 (ie Rock point has Kinsely Campground, Niece Gampground Lookout Gampground,
Minor Campground)

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

[Talk-ca] Searching for addresses...

[G. Michael Carter]

 With the new canvec address data searches like "258 Broadway, 
Orangeville, Ontario" now return the exact spot for that address.  
However, "258 Broadway, Orangeville, ON" returns nothing.   Is this a 
case that we're missing data somewhere or OpenStreetMap.org search is 
not handling abbreviations?


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

[Talk-ca] Ignore that last question I figured it out.

[G. Michael Carter]

 Seems JOSM has a tag on the object called action

http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] How does JOSM save Changes?

[G. Michael Carter]

 My computer froze last night.   I think it missed only the 
relationships.How does JOSM save fact there is a change to an object 
in the OSM file?


I get the following from my working file:

[mcar...@liandra Changes]$ grep "I want to verify it got all the changed ways/nodes from the file.  If so 
I'll just make a manual file for the missing relations.






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

[Talk-ca] Fwd: Copying campsite numbers and features to OSM

[G. Michael Carter]

Thought I'd pass this on to the community.

-- Forwarded message --
From: Ontario Parks - Comments (MNR) 
Date: Mon, Aug 9, 2010 at 9:00 AM
Subject: RE: Copying campsite numbers and features to OSM
To: mi...@carterfamily.ca


Dear Michael,

Thank you for your email.  Yes, you may copy the site numbers, comfort
station, water pump and other object locations from the reservation
system maps, provided that you do not publish the maps themselves.
Please note that the maps on the reservation system are not to scale, so
you may find variations from the map to what is on the ground.

If you do publish any information that is taken from the maps (i.e. that
you have not verified yourself), it will be necessary to credit the
information source.  If you require wording around this, please let us
know.

Sincerely
Ontario Parks


-Original Message-
From: mi...@carterfamily.ca [mailto:mi...@carterfamily.ca]
Sent: July 29, 2010 9:00 AM
To: Ontario Parks - Comments (MNR)
Subject: Copying campsite numbers and features to OSM

Name: G. Michael Carter

Subject: Copying campsite numbers and features to OSM

Park Name:

Comments: Every year I visit at least three of Ontario's Parks camping.
I've started a mini project to map out the camp roads, sites, water
locations, etc... for each camping trip.  Then upload this data on
OpenStreetMap.org for all to use.   (including the parks if they so
wish)

Here's and example of my last trip:
http://www.openstreetmap.org/?lat=44.32926&lon=-79.31917&zoom=17&layers=
M

Could I get permission to copy the site numbers, comfort station, water
pump, and other object locations from the reservation system maps.  When

I'm at the park I plan on verifying all the objects with my GPS, however

if I could get permission to copy these things from your reservations
maps
I could get a rough start.

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

[Talk-ca] 052A06.zip Missing

[G. Michael Carter]

All of 052A is there except 
http://ftp2.cits.rncan.gc.ca/osm/pub/052/A/052A06.zip (Thunder Bay)


Did something happen in that grid?

Michael

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

Re: [Talk-ca] [OSM-talk] Coastline missing in Lake Superior - in case anyone notices...

[G. Michael Carter]

What do you mean "break in the middle due to a timeout"?

As for the race... the only race is the availability of people.  If I
know of a group of, or single, mapper(s) that are going to be in an
area... I like to get the canvec data in that area so they have a base
to work from, and can correct the data while there.   (hence why I'm
all over the map with my edits.)

Michael

On 10/08/10 03:16 PM, Richard Weait wrote:

  As Quick Draw McGraw would say, "Whoa!  Hold on there Pardners!"

Please don't just delete and replace a large international body of
water without TONS of discussion with the affected community first.

There is a very high likelihood that editing an object this large will
break in the middle due to a timeout.  That will make fixing it ever
harder.  And it will all take time which is almost certain to cause a
ruckus, if the affected community is not involved before the problem
occurs.

This in not a race.  There is no deadline or prize for changing inland
seas fastest.

Please reconsider this!

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



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

Re: [Talk-ca] [OSM-talk] Coastline missing in Lake Superior - in case anyone notices...

[G. Michael Carter]

I'm perfectly fine killing the "coastal" tag from the Canadian side on 
all fresh water lakes... makes more sense to me.   Plus it doesn't 
import very well into my Garmin GPS anyways...   you end up pulling half 
the globe just to get the "connecting lines", since it's not a single 
object.


Michael

On 10/08/10 02:52 PM, John Smith wrote:

On 11 August 2010 04:51, Sam Vekemans  wrote:
   


a 'lake' and 'shoreline' are 2 different map features.
 

We don't get the sorts of levels of water as they do in North America
so to me a shoreline is only along the sea shore...

Where as bodies of fresh water are usually lakes (natural=water)...
   



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

Re: [Talk-ca] Coastline missing in Lake Superior - in case anyone notices...

[G. Michael Carter]

I thought of that, but I'm dealing with over a million coastline
objects.   Seemed quicker and less prone to screw ups if I just deleted
the object and add natural=coastline to the canvec body of water. 
(There's a lot of coastal islands and stuff I'm contending with too...)

Michael

On 10/08/10 02:29 PM, Sam Vekemans wrote:

  what im doing is keeping the coastline in tact, and adding in more
detail as i go along, and merging the nodes with the land/water
features edge as i go along.


you might want to message the talk-us list as you go along.


cheers,
sam

On 8/10/10, G. Michael Carter  wrote:
  
  
I'm currently working on importing CanVec data around Lake Superior...
the coast line was really getting in the way, so I'm deleting it.  I'm
actually joining them to the CanVec water corners... but it's probably
creating a coastal hole, not really sure if the join is actually working.

My plan is to finish loading all the coastal areas with the canvec
data.  Then joining the big body of water with a single relation, on the
Canadian side.   That will become the new coastal waters object, when
finished.  On the USA side I'll just join the existing coastal waters
object across the USA/Canada boarder.

I should have the entire lake finished by the end of the week... I
hope.   I just wanted to post this in case it sent up red flags somewhere.


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


  
  

  



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

[Talk-ca] Coastline missing in Lake Superior - in case anyone notices...

[G. Michael Carter]

I'm currently working on importing CanVec data around Lake Superior... 
the coast line was really getting in the way, so I'm deleting it.  I'm 
actually joining them to the CanVec water corners... but it's probably 
creating a coastal hole, not really sure if the join is actually working.


My plan is to finish loading all the coastal areas with the canvec 
data.  Then joining the big body of water with a single relation, on the 
Canadian side.   That will become the new coastal waters object, when 
finished.  On the USA side I'll just join the existing coastal waters 
object across the USA/Canada boarder.


I should have the entire lake finished by the end of the week... I 
hope.   I just wanted to post this in case it sent up red flags somewhere.



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

Re: [Talk-ca] Any way to "dirty" large areas of Mapnik?

[G. Michael Carter]

Play with this:

#!/usr/bin/python
from math import pi,cos,sin,log,exp,atan,ceil,floor,radians,tan
from subprocess import call
import sys, os
from Queue import Queue
import mapnik
import threading

def deg2num(lat_deg, lon_deg, zoom):
   lat_rad = radians(lat_deg)
   n = 2.0 ** zoom
   xtile = int((lon_deg + 180.0) / 360.0 * n)
   ytile = int((1.0 - log(tan(lat_rad) + (1 / cos(lat_rad))) / pi) /
2.0 * n)
   return(xtile, ytile)


def minmax (a,b,c):
    a = max(a,b)
    a = min(a,c)
    return a

def dirty_tiles(bbox):
    for z in range(5,18):
    str_z = "%s" % z
    px0 = deg2num(bbox[1], bbox[0], z)
    px1 = deg2num(bbox[3], bbox[2], z)
    #print px0, px1
 
    for x in range(int(px0[0]),int(px1[0])+1):
    str_x = "%s" % x
    for y in range(int(px0[1]),int(px1[1])+1):
    str_y = "%s" % y
    dirty_uri = 'curl http://b.tile.openstreetmap.org/' +
str_z + '/' + str_x + '/' + str_y + '.png/dirty; sleep 2;'
    print dirty_uri


if __name__ == "__main__":
    home = "."
   
#-
    #
    # Change the following for different bounding boxes and zoom levels
    #
    # Start with an overview

#    if  sys.argv[0] is None:
#    print "usage dirty.py: tilename max_lat max_lon min_lat
min_lon"
#    exit


    bbox =
(float(sys.argv[2]),float(sys.argv[3]),float(sys.argv[4]),float(sys.argv[5]))
#    bbox = (-87.0,49.0,-82.0,45.0)
#    bbox = (-81.0,52.0,-70.0,38.0)
    print "#",sys.argv[1],":",bbox
    
    dirty_tiles(bbox)



On 08/08/10 08:26 PM, Tyler Gunn wrote:

  
Is there any easy way to "dirty" large areas of the Mapnik map at all zoom
levels?  I'm working on the 062N* tiles in Canvec and there's a fair number
of tiles at different zoom levels that are not properly refreshed:

For example:
http://www.openstreetmap.org/?lat=51.529&lon=-100.42&zoom=9&layers=M
http://www.openstreetmap.org/?lat=51.547&lon=-101.033&zoom=10&layers=M
http://www.openstreetmap.org/?lat=51.564&lon=-101.206&zoom=11&layers=M

Notice that some areas are fine at some zoom levels where the same areas
are not at other levels.  

I am not about to go and do the whole "/dirty" thing on all the tiles that
are not rendering correctly. :)



  



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

Re: [Talk-ca] Any way to "dirty" large areas of Mapnik?

[G. Michael Carter]

If there isn't way to do a large area then the next question would be 
how does one get a list of all the tiles under one of your urls.


If you can get a list you could script the /dirty on the end and just 
run it through curl or wget.


http://svn.openstreetmap.org/applications/rendering/mapnik/generate_tiles.py  
might be a good starting point.


Mikey

On 08/08/10 08:26 PM, Tyler Gunn wrote:

Is there any easy way to "dirty" large areas of the Mapnik map at all zoom
levels?  I'm working on the 062N* tiles in Canvec and there's a fair number
of tiles at different zoom levels that are not properly refreshed:

For example:
http://www.openstreetmap.org/?lat=51.529&lon=-100.42&zoom=9&layers=M
http://www.openstreetmap.org/?lat=51.547&lon=-101.033&zoom=10&layers=M
http://www.openstreetmap.org/?lat=51.564&lon=-101.206&zoom=11&layers=M

Notice that some areas are fine at some zoom levels where the same areas
are not at other levels.

I am not about to go and do the whole "/dirty" thing on all the tiles that
are not rendering correctly. :)



   



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

Re: [Talk-ca] CanVec Boundries?

[G. Michael Carter]

  | CanVec 6.0 - NRCan | 
2010-07-06 17:56:23 |  23 |   0 | -



On 06/08/10 08:38 AM, Sam Vekemans wrote:

r u using the nrcan wns layer that has the nts grid #'s?


i also use marble desktop it helps to see what has/hasnt been imported.


are you able to update the main google docs chart? :

cheers,
sam


and no, we dont have the quad-tree tile boundaries, but its easy as
its  1/4 of the area.

On 8/6/10, G. Michael Carter  wrote:
   

Do we have the lat/long boundaries of the new canvec tiles anywhere?
(that why I don't have to download all of canada to get them)

Mikey


 


   



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

[Talk-ca] CanVec Boundries?

[G. Michael Carter]

Do we have the lat/long boundaries of the new canvec tiles anywhere?  
(that why I don't have to download all of canada to get them)


Mikey

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

[Talk-ca] Tags.. Showers, Camp Store, Trailer dumping?

[G. Michael Carter]

I've mapped out Rock Point Provincial Park (well 98% of it I'd say) and 
how do I tag the Trailer Dumping area, Camp Store, and the comfort 
stations with showers and laundry?


Mikey

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

Re: [Talk-ca] Merging CanVec data, updating status

[G. Michael Carter]

I'll have to upload my scripts for pulling and process Planet files
later (after Tues).  I'm packing for camping, working, and poking at
the psql to see if I can pull a map of who's imported objects into
grids, and when the last update was. (only for ontario, but I have the
change files from Jan, 2010 so it could be possible to scan for all of
Canada.)

I'll have more on Tuesday when I come back from camping thought.

Michael

On 30/07/10 12:20 PM, Tyler Gunn wrote:

  
On Fri, 30 Jul 2010 11:06:47 -0400, "G. Michael Carter"
 wrote:
  
  
I think the spreadsheet is the wrong way to go where.   We need an app, 
that will show like this image below.  Nice and easy to pick which grid 
to do next.

  
  
That would definitely be the best solution.  MUCH more visual.

  
  
I've actually been toying with an idea.   I pull daily planet files onto

  
  
  
  
my server and mask out Ontario for building up-to-date maps for my 
garmin.  It shouldn't be too hard to match up % of CanVec data on a 
grid, and who put it in.  (would be easier of the CanVec ID's were 
intact... but oh well)   I'll have to think about the idea while I'm 
camping this weekend...

  
  
Okay, I realize this is a bit of a diversion; but how are you pulling
daily planet files onto your server?  I have tried to do a similar thing to
get the planet.osm file onto my own server so I can extra MB maps
regularly.  However, it seems I can NEVER get a good planet.osm download;
they're always corrupts.  Or did you start with JUST a download of Ontario
(using the XAPI API) and are just applying the planet diffs to that?

Thanks,
Tyler

  



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

[Talk-ca] Merging CanVec data, updating status

[G. Michael Carter]

Did anyone hear that loud bang last night...?  That was my head 
repeatedly hitting the table while I repeated the words "look before you 
leap!" :-)


I spent 1 hour updating and processing a CanVec tile.  When I was 
finished I ran the verification step and fixed duplicates.   Then when I 
started to go through the duplicates, I noticed +12,000 duplicate nodes 
and over 5,000 duplicate ways (or something like that).   Upon further 
investigation, andrewpmk had already processed and uploaded the grid.  
*grin*   That's what I get for taking a short cut and downloading the 
current data into the CanVec layer and processing it all at once.  
(which I do in the barren areas which no real city data yet)


Needless to say I've gone through andrewpmk's edits list and updated 
https://spreadsheets.google.com/ccc?key=0Ati4aAtBXfTVdERaUWZPNWhxTDJFOTF4STFLa25HbVE&hl=en 



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.


Michael


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

Re: [Talk-ca] Joining Trails to roads.

[G. Michael Carter]

That sites assume!   Most problems you can't obviously see, so it's
going to be a big help.   How often is the data updated?

On 29/07/10 09:50 AM, john whelan wrote:
I use IE with http://keepright.ipax.at it finds
all sorts of things that need correcting but you can limit it to pick
out these.  Getting hold of all the editors in a particular region,
very unlikely some only edit for one session for a start.
  
Cheerio John
  
  
  
  On 29 July 2010 09:24, G. Michael Carter <mi...@carterfamily.ca>
wrote:
  
As my previous e-mail I've
been playing around with routing based on
pedestrian and cycling.   I'd say, in my area, 1 in 20 trails are
connected to the roads.   I checked the Toronto and Brampton area. 
Same issue.

Trails that cross roads, need to have a connecting node.   Also they
need to join up with a road.  Most trails don't join with the road but
they need to for the routing to work.   Also my solution for trails
that end at a parking lot.  I've been just pulling the trail around the
perimeter of the parking lot till we get to the road.  (that way
routing works)

Since I didn't know trails needed to be connected to roads, I thought
I'd mention it.   Is there any way we can reach all the editors of the
GTA area?  As they have a lot of trails falling in this category.

Example:




Michael


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

  
  
  



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

[Talk-ca] Joining Trails to roads.

[G. Michael Carter]

As my previous e-mail I've been playing around with routing based on
pedestrian and cycling.   I'd say, in my area, 1 in 20 trails are
connected to the roads.   I checked the Toronto and Brampton area. 
Same issue.

Trails that cross roads, need to have a connecting node.   Also they
need to join up with a road.  Most trails don't join with the road but
they need to for the routing to work.   Also my solution for trails
that end at a parking lot.  I've been just pulling the trail around the
perimeter of the parking lot till we get to the road.  (that way
routing works)

Since I didn't know trails needed to be connected to roads, I thought
I'd mention it.   Is there any way we can reach all the editors of the
GTA area?  As they have a lot of trails falling in this category.

Example:




Michael


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

Re: [Talk-ca] Labelling camp site numbers.

[G. Michael Carter]

This is what I hate about copyright.  

So if copying the name "Forest Lawn" or Campsite 19 from a map it's a
violation.  What about copying the name from the official website?  is
copying the name of the Ontario Science Centre from

http://www.ontariosciencecentre.ca/
a violation?  (like I just did for this e-mail)   What about standing
in front of the campsite post writing down the number?  It's also also
a violation as I'm "copying" the number?  What about remembering the
number?   As I said below, being able to copyright maps is the
stupidest idea I've ever seen.  Are the going to start copyrighting the
landscape so an artist can't draw it next?  I'm sure someone's tried.

Seems the only way to avoid copyright is to burn more holes in the
OZONE layer and drive over to the location and redo surveys already
done by several other people burning holes in the OZONE layer...

Sorry... went on a tangent...  :-) 

Mikey

On 28/07/10 06:49 PM, Gerald A wrote:

  
  On Wed, Jul 28, 2010 at 6:08 PM, G. Michael
Carter <mi...@carterfamily.ca>
wrote:
  1.
 If I grab the camp site numbering off the reservations website and/or
campground maps would that be a violation of copyright?
  
  
Yes, for sure. Shift the question to a more mainstream map: "If I copy
street names off a map, is it a copyright violation?"
  
But, since this might be for business benefit, you could explain it to
the copyright holder (the camp site owner) and ask for the data
to be licenced. Campground operators would only benefit from this. (The
province is a big operator too, but there is other considerations
for ministries, unfortunately).
  
  
  Side
question:  Is it a violation to pull the names of object from google?  
(ie:  Forest Lawn Cemetery?)  Does google have copyright traps like
purposely miss-spelling names to catch copyright violators.
  
  
Yes, it's a violation to copy stuff off of Google. Unless the person
who has the copyright waves it, it's a violation.
  
OSM has always been on the conservative side of thing with this, and
rightly so.
  
Gerald
  
  



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

[Talk-ca] Labelling camp site numbers.

[G. Michael Carter]

A few months ago I entered the roads for campgrounds specifically : 
http://www.openstreetmap.org/?lat=44.32948&lon=-79.3248&zoom=16&layers=M


It's not complete but a good start.   I had two thoughts.

1.  If I grab the camp site numbering off the reservations website 
and/or campground maps would that be a violation of copyright?


2.  Do we have any rules around adding it?  Or should I just follow how 
the CanVec data has done the addr: tags?



Side question:  Is it a violation to pull the names of object from 
google?   (ie:  Forest Lawn Cemetery?)  Does google have copyright traps 
like purposely miss-spelling names to catch copyright violators.


Man copyright on maps is so silly in my mind. :-)

Michael

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

[Talk-ca] Routing-Trails

[G. Michael Carter]

Seems "walking" routable maps use the trails only if their connected to 
the roads.


ie: 
http://maps.cloudmade.com/?lat=43.906319&lng=-80.13696&zoom=16&directions=43.902082417856064,-80.13610124588013,43.909333095564016,-80.12887001037598&travel=foot&styleId=1&opened_tab=1



So any ideas how to handle if the trail is connected to a parking lot?

Mikey

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

Re: [Talk-ca] Hiking trails - Is bad data better than no data?

[G. Michael Carter]

You have my vote.  Just having the inaccurate data will draw more people to the 
trail.  Higher percent chance of getting more gps data for the area.

Sent from my iPhone

On 2010-07-25, at 10:57 PM, Darryl Shpak  wrote:

> Hey all,
> 
> A quick question here, since I'm somewhat out-of-touch with OSM best 
> practices right now. Last week I hiked a couple of trails in a local 
> provincial park, and collected traces with intent to map them. However, I 
> know the data is of questionable quality...on the first trail, I walked one 
> segment twice and there's a significant disparity between the two gps tracks, 
> and on the second trail, my GPS was reporting 20-30m position error at times.
> 
> Neither of these trails existed in OSM at all (no GPS tracks, no ways). I've 
> uploaded my GPS traces and I'm mapping my trails on the assumption that an 
> inaccurate trace is better than no data at all, but wanted to check with the 
> wider community to see what the general consensus was on this. Is there 
> anything special I should tag the trace or way with to indicate that I know 
> the tracks are a little flaky?
> 
> Sample trail:
> http://www.openstreetmap.org/?lat=49.69252&lon=-95.33649&zoom=16&layers=M
> 
> - Darryl
> 
> 
> ___
> 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] CanVec Data Oddities

[G. Michael Carter]

The first problem is how JOSM select objects.  If a node is shared
between a wood, marsh, body of water, and rapids.  Deleting the wooded
area shouldn't remove the node from the other three as well.   When I
remove the wooded area on one object the water disappears and the
rapids turn into, what looks like two triangles touching each other.   :-)   

So that one there's no change needed to the CanVec Data, just that
people deleting objects for an import need to be aware that it can
change the surrounding objects of your not watching.   After that
e-mail, I came up with the following to separate the CanVec data into a
Navigation only layer.   That way I wouldn't have to "delete" anything
in JOSM.  The only problem I haven't worked out yet is dealing with
multi-polygons, as the inner/outer objects have no tags so there's
nothing to filter on in the osmosis tool.  (and the sed commands are
because the CanVec data is not formatted correctly as a V6.0 file.  
version and timestamp are required in V6.0 of an osm file, but it's
easily added by sed)

    sed "s/
  sed "s/
  sed "s/
  osmosis --read-xml file="/dev/stdin" \
    --tf accept-ways addr:interpolation=* highway=* addr:city=* \
    --tf accept-relations highway=* \
    --used-node --write-xml $DirName/navigation-$BaseName.osm

The other issue was things like "sports tracks" that spanned two
tiles.   Most objects have the two points on the border connecting so
that the object is a closed object.  Sports tracks are like a two horse
shoes.   They join no problem but only if both tiles are imported.   If
only one tile is imported you'll have a very weird looking objected as
it's expecting it to be closed.   Not really a problem with the CanVec
data, just something to be aware of when importing.

Michael


On 19/07/10 08:23 AM, Bégin, Daniel wrote:

  Hi Michael,

I'm not sure I understand the problem you describe.  Is it a problem with the geometric model?

However, there is something I'm sure of - Nodes must be merged at Canvec tile limits to keep data integrity.

Daniel

-Original Message-
From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter
Sent: 18 juillet 2010 10:40
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] CanVec Data Oddities

I've been noticing some very rare occurrences where the track, park and campsite objects didn't make sense.  Found two causes:

1.  When deleting objects, like says woods, if it shares common nodes with another object like a campsite or rapids there's a 50/50 chance the 
delete will delete the shared nodes.   This is what I've found doing a 
recent object.   So something to look out for.

2. If the object is right on a CanVec border sometimes the way is not 
connected.   So you need to pull both tiles to get the complete object.



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



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

Re: [Talk-ca] CANVEC data OSM files

[G. Michael Carter]

I just started "selecting" things like this:

sed "s/timestamp=\'2009-08-11T15:16:48Z\' /g" $x | \
  sed "s/timestamp=\'2009-08-11T15:16:48Z\' /g" |\
  sed "s/timestamp=\'2009-08-11T15:16:48Z\' /g" |\

  osmosis --read-xml file="/dev/stdin" \
--tf accept-ways addr:interpolation=* highway=* addr:city=* \
--tf accept-relations highway=* \
--used-node --write-xml $DirName/$BaseName-navigation.osm


That way I can do the roads as one set.

On 18/07/10 01:19 PM, john whelan wrote:

Looking through them locally I can see lots of data I'd like to lift
out of them but some roads are a problem.  Within the City of Ottawa I
can see unpaved roads which are already in done with a GPS trace that
are not in the CANVEC files and some newer residential roads are
missing that have been imported previously.  One in particular was
from a Geobase_Import_2009 and even that one the new bit next to it
wasn't even in the Geobase import.  Looks like I'll need to clean up
gently, it would have been nice to do a global replace on a number of
existing roads that had been created from GPS traces, just the ones
with 1,000 points per kilometer in a straight line.

I'd like to pull in the house numbers but so far I haven't worked out
how to select them to copy them in.  Any one any suggestions?

Thanks John

___
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] User sundance

[G. Michael Carter]

So what's the story on VReimer?

On 18/07/10 12:18 PM, Tyler Gunn wrote:

  
On Sun, 18 Jul 2010 09:15:55 -0700, Sam Vekemans
 wrote:
  
  
cool, thanks for clearing that up :)
i guess its always good to assume its ligit before jumping to
conclusions. as getting messages from multiple people, would annoy
anyone.
as we do this part time, not everyone checks their email every second.
so would even streatch it to a week for responding.
sam

  
  
Yes, we should definitely assume innocent until proven guilty.   :)  Lol. 


I'm glad I only have to worry about VReimer's data now (although there's
lots of that to clean up).  :)

Tyler

  



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

[Talk-ca] CanVec Data Oddities

[G. Michael Carter]

I've been noticing some very rare occurrences where the track, park and 
campsite objects didn't make sense.  Found two causes:


1.  When deleting objects, like says woods, if it shares common nodes 
with another object like a campsite or rapids there's a 50/50 chance the 
delete will delete the shared nodes.   This is what I've found doing a 
recent object.   So something to look out for.


2. If the object is right on a CanVec border sometimes the way is not 
connected.   So you need to pull both tiles to get the complete object.




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

[Talk-ca] Deleting existing roads...

[G. Michael Carter]

OK this is really starting to bother me.   Roads are scary!!!

I tried seeing if I could take two CanVec block and merge them with
existing roads.   Well I created a mess and ended up deleting the
blocks.   CanVec data has many little differences... ie: where the
nodes are, barriers, location of the roads, the break points between
grids, road names... see below (grey CanVec), purple GPS, and orange
existing GeoBase.   I even had an entire section in a ski resort that
the GeoBase had no names (15 ways), where CanVec does and has road
barriers too.  I have a feeling the GeoBase uploaded to Ontario was
something like V5.0 where the CanVec is V6.0 data.  Every difference
I've found has proven to be more accurate.

I have to make like 500-1000 changes per grid if I try to modify
existing GeoBase.   If I do it the other way around, and replace the
GeoBase.. I'm finding I have 20, if any, changes per grid.  With 500+
changes my change of making a mistake --like not connecting the roads
properly for routing-- increase.   CanVec roads line up and connect
perfectly with CanVec roads, and other CanVec data.

So my question here:

How much of a problem is it if I miss tags like "one-way" or move a
road that was placed via something other than GPS trails.   By
replacing the GeoBase/Yahoo roads, then adding and connecting the few
that CanVec is missing?  Plus adding the few tags that I find.  

Personally I see more benefit to using CanVec road data.  Like the
screen shot below, CanVec Road Network,  lines up with GeoBase 90% of
the time and Yahoo maybe 25%.  In every case I've seen CanVec data
lines up better with GPS data.   Also the CanVec data is going to line
up better with other objects in CanVec, like forests, green spaces, and
address information.   It's just way eaiser to replace the existing
roads with CanVec, then modify the CanVec to fit any problems, than the
other way around.

I just don't want to piss anyone off here.   I've done 70 tiles so far
and just wanted to get keep going/no go from the community before I
continue.  






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

Re: [Talk-ca] Tracking who's working on which CanVec tile?

[G. Michael Carter]

Anyone have the link for the google chart handy?



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

Re: [Talk-ca] Duplicate overlapping roads...

[G. Michael Carter]

I've attached the two examples.   Our family goes for a walk around 
these streets nightly and I've taken my gps with me.  The CanVec data is 
bang on.   GeoBase is close but as I've said, CanVec is closer.


Mikey

On 13/07/10 09:22 AM, Bégin, Daniel wrote:

Michael,
Yes, the data before and after,
or the coordinates where you found the differenmce (we already have 
GeoBase and canvec Data)

Regards,
Daniel




  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  







































  
  









































  
  














  
  




















  
  

















  
  













  
  















  
  












  
  














  
  


















  
  













  
  













  
  
















  
  
















  
  












  
  













  
  













  
  












  
  












  
  














  
  














  
  











  
  













  
  





















  
  












  
  












  
  












  
  












  
  













  
  













  



  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  











  
  









  
  







  
  







  
  












  
  









  
  







  
  







  
  







  
  














  
  








  
  















  
  











  
  






























  
  





















  

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

Re: [Talk-ca] Duplicate overlapping roads...

[G. Michael Carter]

connectivity was one of the reasons many reasons for my process.  All
the CanVec data lines up with itself quite nicely.  

Can you give me a list of all these post-geobase activities (or at
least as many as you know of).   I can easily modify my filters to
detect them, if I know what I'm looking for.

Mikey

On 13/07/10 12:43 AM, Michael Barabanov wrote:
Another typical post-geobase exercise is to connect to
existing roads and fixing connectivity problems otherwise. This is
really important for routing, e.g. in Garmin GPS. I for one spent quite
a bit of time doing this for my area.  I guess the upshot is: be
careful when deleting data that could have been manually adjusted.
  
  On Mon, Jul 12, 2010 at 8:24 PM, Michael
Barabanov <michael.baraba...@gmail.com>
wrote:
  forgot
talk-ca



On Mon, Jul 12, 2010 at 8:24 PM, Michael
Barabanov <michael.baraba...@gmail.com>
wrote:

GPS tracks aren't the only source.  There's also Yahoo.  There's local
survey (for things like  that isn't present in geobase).
Also, some people choose not to upload GPS they used for editing.  I
think a good idea would be to see if the import was the last edit for
the data to be deleted, or if there were edits done after the geobase
import.
  
  
  
      On Mon, Jul 12, 2010 at 7:25 PM, G.
Michael Carter <mi...@carterfamily.ca>
wrote:
  
Since I've had 100%
accuracy to my known areas on CanVec data (well
within 5 metres anyways) I'd tend to trust it, over a change to GeoBase
data that has no supporting GPS Tracks.  
:-) 

I am comparing it to the GPS tracks as I go, but like I said there is
many areas where there is no GPS tracks to follow.   Also, something
I've noticed, CanVec data takes into account bends in the road where,
in the areas I'm doing, GeoBase just has a straight line.  (Blind line
in Orangeville is one such road)

I'm sure I'll probably replace some "more" accurate data somewhere, but
the frequency should be pretty low, and with no supporting GPS tracks,
or quoted source, how do we tell anyways?   

Mikey




On 12/07/10 06:35 PM, Michael Barabanov wrote:

  My concern would be with 3. It is possible that someone has edited
imported Geobase data after the import.

On Fri, Jul 9, 2010 at 8:51 AM, G. Michael Carter  wrote:
  
  
Sam always says I should let people know what I'm up to.   Today I'm
actually going to listen... ;-)

I'm working in three areas currently, outward in circles around: Orangeville
(040P), Pickering (030M), and Rock Point PP (030L).   (and trying to pull in
Lake Ontario shore line)

I'm creating some duplicate roads, temporarily, in the process.   I wanted
to detail my process here in case anyone notices them and starts scratching
their head.

The process I'm following:

1.  Remove all existing OSM objects from CanVec grid.  (mostly stuff I've
already uploaded)
2.  Merge with existing OSM data on the layer.
3.  Delete any "attribution:GeoBase highway=*" roads.  Trying to preserve
any roads that CanVec doesn't have but it's hard since a lot of the areas
I'm doing don't have any GPS tracks.
3a.  Where the duplicates come in... I'm leaving any roads that go off grid,
at least to an area I haven't processed yet.  Then when I get to that area I
remove/merge them.
4.  Go over the area and merge/delete any roads manually added or that have
no source (where no GPS track)
5.  Merge any duplicate objects, that I missed or previously existed.

Areas I'm staying away from: Toronto!  I'm not going near that one, too much
existing or conflicting data.  I'll let someone living in Toronto to pick up
that mess. :-)

Mikey

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


  





-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com




  
  
  
  
  





  
  
  



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

Re: [Talk-ca] Routing

[G. Michael Carter]

The address interpolation is on either side of the road, and hover over 
the road and you do get the street name.


On 13/07/10 12:15 PM, Tyler Gunn wrote:
   

However, the find isn't working.  If I click find ->  address.   There is
 
   

no addresses listed.   Is this missing data on my part or a problem with
 
   

mkgmap?
 

This is a problem with mkgmap; it doesn't quite do the addressing data
right yet.
Does your area have the address interpolation ways?

   

Also When I hover over a street it doesn't show the street address.
Again is this something I've missed?  or a limitation of mkgmap?
 

I'm not sure on this one; I know my GPSMap 60CSX does show the street name
on hover over when I use the Lambertus OSM maps.  So I'm guessing it's just
something missing in the Canvec data.  Again, might want to check if the
names are shown in the canvec data.  I know here in MB all the streets are
unnamed in the Canvec data, meaning we need to copy the street names
manually from the Stats Can data.

Tyler

   



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

[Talk-ca] Routing

[G. Michael Carter]

Ok I've loaded just my home town into my Garmin 60cx.

If I click on an intersection and say go-to it draws a nice route with 
all the canvec data I uploaded.


However, the find isn't working.  If I click find -> address.   There is 
no addresses listed.   Is this missing data on my part or a problem with 
mkgmap?


Also When I hover over a street it doesn't show the street address.   
Again is this something I've missed?  or a limitation of mkgmap?


Mikey

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

Re: [Talk-ca] Duplicate overlapping roads...

[G. Michael Carter]

Since I've had 100% accuracy to my known areas on CanVec data (well
within 5 metres anyways) I'd tend to trust it, over a change to GeoBase
data that has no supporting GPS Tracks.  
:-) 

I am comparing it to the GPS tracks as I go, but like I said there is
many areas where there is no GPS tracks to follow.   Also, something
I've noticed, CanVec data takes into account bends in the road where,
in the areas I'm doing, GeoBase just has a straight line.  (Blind line
in Orangeville is one such road)

I'm sure I'll probably replace some "more" accurate data somewhere, but
the frequency should be pretty low, and with no supporting GPS tracks,
or quoted source, how do we tell anyways?   

Mikey


On 12/07/10 06:35 PM, Michael Barabanov wrote:

  My concern would be with 3. It is possible that someone has edited
imported Geobase data after the import.

On Fri, Jul 9, 2010 at 8:51 AM, G. Michael Carter  wrote:
  
  
Sam always says I should let people know what I'm up to.   Today I'm
actually going to listen... ;-)

I'm working in three areas currently, outward in circles around: Orangeville
(040P), Pickering (030M), and Rock Point PP (030L).   (and trying to pull in
Lake Ontario shore line)

I'm creating some duplicate roads, temporarily, in the process.   I wanted
to detail my process here in case anyone notices them and starts scratching
their head.

The process I'm following:

1.  Remove all existing OSM objects from CanVec grid.  (mostly stuff I've
already uploaded)
2.  Merge with existing OSM data on the layer.
3.  Delete any "attribution:GeoBase highway=*" roads.  Trying to preserve
any roads that CanVec doesn't have but it's hard since a lot of the areas
I'm doing don't have any GPS tracks.
3a.  Where the duplicates come in... I'm leaving any roads that go off grid,
at least to an area I haven't processed yet.  Then when I get to that area I
remove/merge them.
4.  Go over the area and merge/delete any roads manually added or that have
no source (where no GPS track)
5.  Merge any duplicate objects, that I missed or previously existed.

Areas I'm staying away from: Toronto!  I'm not going near that one, too much
existing or conflicting data.  I'll let someone living in Toronto to pick up
that mess. :-)

Mikey

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


  



-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

[Talk-ca] Duplicate overlapping roads...

[G. Michael Carter]

Sam always says I should let people know what I'm up to.   Today I'm 
actually going to listen... ;-)


I'm working in three areas currently, outward in circles around: 
Orangeville (040P), Pickering (030M), and Rock Point PP (030L).   (and 
trying to pull in Lake Ontario shore line)


I'm creating some duplicate roads, temporarily, in the process.   I 
wanted to detail my process here in case anyone notices them and starts 
scratching their head.


The process I'm following:

1.  Remove all existing OSM objects from CanVec grid.  (mostly stuff 
I've already uploaded)

2.  Merge with existing OSM data on the layer.
3.  Delete any "attribution:GeoBase highway=*" roads.  Trying to 
preserve any roads that CanVec doesn't have but it's hard since a lot of 
the areas I'm doing don't have any GPS tracks.
3a.  Where the duplicates come in... I'm leaving any roads that go off 
grid, at least to an area I haven't processed yet.  Then when I get to 
that area I remove/merge them.
4.  Go over the area and merge/delete any roads manually added or that 
have no source (where no GPS track)

5.  Merge any duplicate objects, that I missed or previously existed.

Areas I'm staying away from: Toronto!  I'm not going near that one, too 
much existing or conflicting data.  I'll let someone living in Toronto 
to pick up that mess. :-)


Mikey

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

[Talk-ca] Second Priority request.

[G. Michael Carter]

Now that I have everything from the first priority request... opps I 
have a hole in my grid.  I forgot to request 041 A.   PLEASE. :-D



Thanks,
Michael



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

[Talk-ca] JOSM Difference?

[G. Michael Carter]

Is there any way to apply a minus on the OSM files?   ie:  Select a 
CanVec grid, and open in JOSM.  Then click a download button and it 
removes any object which are identical?





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

[Talk-ca] Accuracy of CanVec vs Yahoo?

[G. Michael Carter]

When importing the data do we favour yahoo existing data in OSM (which
is obviously traced from satellite imagery)  or CanVec?   I'm assuming
CanVec for parks would be based on official park boundaries rather than
yahoo, line of site on open spaces.   So parks would be better coming
from CanVec.  But what about buildings?

Mikey


-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

[Talk-ca] Priority on OSM/CanVec

[G. Michael Carter]

Could I get a higher priority on:

031 C - Bon Echo PP area
031 D - Barrie
031 E - Algonquin 
031 F - Algonquin 
041 H - Parry Sound
041 L - Killarney PP area

Thanks,
Michael
-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

[Talk-ca] CanVec Data

[G. Michael Carter]

How close are we to getting these released?  I'm anxious to get started.

Will we have the option to get these in 50k blocks?   All the current 
canvec data I've imported is in the 50k blocks thus the new data should 
fit nicely.




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

[Talk-ca] OSM CanVec.

[G. Michael Carter]

I think I may have missed the goal here?   Are we evaluating the OSM 
files and trying to make the source better or just requesting OSM files 
and putting them in?

I'm ready to go if we're just putting them in. ;-)

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

[Talk-ca] 040P16 - Orangeville

[G. Michael Carter]

Hey I can see my house in there!   Amazing job!!

Looks great.   Few things I found so far.

Data is out of date in many areas.  

  Lakes no longer there.   (drained a few years ago and
re-landscaped).
  Also the residential area stops in the north-west end, et all the
roads
for the residential areas are still there.
  Alder street rec centre
and the westside secondary high school are not there.
  There's a sports track going through Walmart, Canadian Tire, and
Futureshop.
  


Didn't know if you wanted to know about the data issues.

The OSM tags:


  None of the school buildings are named?  Is this an oversight or
just not in the CanVec data?
  Cemeteries don't have names either?  Is this an oversight or just
not in the CanVec data?
  Orangeville District Secondary School.  is a multi-polygon.  The
outer and inner objects don't have any tags.
  All the lakes have duplicate ways.
  Multi-polygon residential areas don't have any tags same as the
school.  I suspect none of the multipolygon's have tags.

That's all I see so far.

But amazing work!

Mikey


-- 
G. Michael Carter

Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com






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

[Talk-ca] Canvec.osm Future...

[G. Michael Carter]

I know I'm jumping way way ahead... but once we get all the CanVec.osm 
files imported for all of Canada... what happens with the next version 
of CanVec data?

Are there going to be diff files or is there a program out there to 
compare the difference of current OSM data to a new file?



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

Re: [Talk-ca] Canvec.osm sample files are ready

[G. Michael Carter]

Any possibility of getting 041P16 (Orangeville) area as a sample.  It's 
where I live.   Figure local knowledge would be a good way to verify the 
area too ;-)

Mikey


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

[Talk-ca] PR person for Canada/Ontario?

[G. Michael Carter]

Do we have a PR person for OSM in Canada?

I've had this idea rolling around in my head.   Years ago, when I was
in high-school, the teacher of geography had us map out our local
plaza.  Most of us just paced out the dimensions of the parking lot,
locations of the building, and any features, then we had to draw it all
to scale.  We got marks on accuracy.    

I thought it would be amazing if they taught this in schools from an
OSM perspective.   Have the students pick target.  (eg: park, their
school, local plaza, what ever)   Then have them map out the area based
on GPS co-ordinates and taking measurements.   Then have that data
uploaded to OSM.   

I've tried three times to draft up a letter to my local MP and the
Minister of Education but can't quite get it right.   Do we have any PR
experts which could run with the idea?

Mikey

-- 
G. Michael Carter

Contact: sip:mikeycar...@fedoraproject.org
| H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F:
1-519-941-0009 
Google Talk: xmpp:mikeycarter1...@gmail.com





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