Re: [Talk-ca] Question

[Jarek Piórkowski]

Hi,

Thanks for the feedback! It helps a lot to have information from real
world users.

I looked into the data briefly. The data that _has been_ entered in
OpenStreetMap looks correct. However, much data is not available.


A brief explanation of what is happening:

Postal codes are potentially incorrect, but these are currently mostly
not tagged in OSM in Québec. Instead, a search engine called Nominatim
is guessing them from the surroundings. A particular problem that
happens often is that Nominatim takes in neighbourhood names and
postal codes by centre point, not by boundary. In many cases an
address is within one postal code, but closer to centre-point of
another. Compounding the problem is that many postal codes are not
entered at all, so the system guesses the nearest one it knows.

About the string "Neufchâtel-Est, Les Méandres, Québec, Québec, Québec
(Agglomération), Capitale-Nationale, Québec":
Nominatim will also throw in as many nearby neighbourhood and place
names as it knows, without trying to understand if it makes sense or
is duplicated. Here we have:
- nearest place=neighbourhood: Neufchâtel-Est
https://www.openstreetmap.org/node/3835239037
- nearest place=suburb: Les Méandres
https://www.openstreetmap.org/node/309314795 (although this is
actually closer to the address than Neufchâtel-Est! But Nominatim
wants to have _a_ neighbourhood as well, and no nearer neighbourhood
is tagged)
- nearest place=city, admin_level=8: Québec
https://www.openstreetmap.org/node/30915641
- nearest what it guesses to be "city boundary":
boundary=administrative, admin_level=8: Québec
https://www.openstreetmap.org/relation/2319206
- and so on with "Québec (Agglomération)" at admin_level=6,
"Capitale-Nationale" at admin_level=5, the province at admin_level=4
These are not tagged on the address, they are pulled in from nearby
objects. So it's not OSM errors, though a missing neighbourhood might
be an OSM omission.

Basically the OSM search results are often made up by computers, and
only the information actually "tagged" is thought to be correct. For
example, for https://www.openstreetmap.org/node/4974207123 we know
that: addr:housenumber=920, addr:street="Rue Noël-Carter",
amenity=school, name="Centre de formation professionnelle
Maurice-Barbeau". OpenStreetMap doesn't know what the postal code is,
and other systems will have to guess at it. Also note that computers
will struggle when one naturally searches for "CFP Maurice-Barbeau"
expecting to find the Centre de formation professionnelle.

Another problem is that exact addresses are often not entered, they
are entered as address ranges ("interpolations") within the block. For
example, the address range https://www.openstreetmap.org/way/104093690
goes from 2945 to 2995 among odd numbers. However apps can struggle
with that: Maps.me for instance will give you a result for "2945 rue
de la Broussaille" but it doesn't understand that 2985 is between 2945
and 2995, and does not have any results for "2985 rue de la
Broussaille".


What we can do to help:
- realistically: tag bigger and more useful / more likely to be
searched for buildings with their own postal codes, and where a street
has only one postal code, enter it
- more work: lobby for the postal code data to be released on a free
license - the current system favours big players with lots of money
who can pay for the data
- much more work: map individual buildings and enter their street
numbers and postal codes, rather than depending on address
interpolations. However this should be lower priority as it would make
more sense to improve the apps' search to understand interpolations


I tested in OSMAnd (version 2.9.3, installed just now from Play Store
and downloaded Québec map) and it found the address "920, rue
Noël-Carter". When searching for "2985 rue de la Broussaille" it found
the 2945, rue de la Broussaille corner address, which is not exact but
in this case very close. However this particular address data hasn't
changed in a long time, so it seems unlikely that your OSMAnd data
would be out of date...

Potentially of interest for you: the app Maps.me is another app of
OpenStreetMap data with offline routing/GPS on Android. In the test,
it finds "920, rue Noël-Carter", though not "2985 rue de la
Broussaille". If you like, you could test it out to see if it works
better for you. It is free, although it has hotel and travel ads, and
I am guessing it might track your searches.


--Jarek

On 27 April 2018 at 23:00, Pier Luc  wrote:
> Hello, I live in Quebec City. I tried to use OSMand (based on OSM) in my
> City using offline mode and the OBF file of the Province of Quebec. Every
> time I search an address it can not find it! Sometime it offer me other
> address, sometime not. It's like if only a tiny part of Quebec's address had
> been insert in Open Street Map. But, it's not exactly the case because is
> has more address in Open street Map website.
>
> Look at that example, searching: 2985 rue de la Brous

Re: [Talk-ca] Question

[James]

Canada Post also regularly changes Postal Code locations to remain the
master of the postal codes  and be able to resell their 5000$/year database(
https://www.canadapost.ca/cpo/mc/assets/pdf/business/pc_latLong_specs_en.pdf).
They have also sued geocoder.ca for collecting user postal codes, which
resulted in many years of litigation and they finally gave up (non-win).

On Fri, Apr 27, 2018 at 5:26 PM, john whelan  wrote:

> Post codes are put in one at a time.  They aren't all there.
>
> If you could help clean them up that would be useful.
>
> Zip codes are different and belong in Donald's land.
>
> Cheerio John
>
>
>
>
> On Fri, 27 Apr 2018, 5:01 pm Pier Luc,  wrote:
>
>> Hello, I live in Quebec City. I tried to use OSMand (based on OSM) in my
>> City using offline mode and the OBF file of the Province of Quebec. Every
>> time I search an address it can not find it! Sometime it offer me other
>> address, sometime not. It's like if only a tiny part of Quebec's address
>> had been insert in Open Street Map. But, it's not exactly the case because
>> is has more address in Open street Map website.
>>
>> Look at that example, searching: 2985 rue de la Broussaille.
>> Osmand can't find it by OSM web site gives:
>>
>> Maison 2985, Rue de la Broussaille, Neufchâtel-Est, Les Méandres,
>> Québec, Québec (Agglomération), Capitale-Nationale, Québec, G2C 0G3, Canada
>> 
>>
>> I think it has a problem there. A lot of information should not be there
>> and the zip code is bad. It should be G2C 1S1. If that address is in the
>> OBF, I supposed the app have difficulties to find it.
>>
>> The good address is: 2985, Rue de la Broussaille, Québec, QC, G2C 1S1,
>> Canada
>>
>>
>> An other test: 920, rue Noël-Carter
>>
>> Osmand can't find it but OSM web site can:
>>
>>
>> École Centre de formation professionnelle Maurice-Barbeau, 920, Rue
>> Noël-Carter, Sainte-Foy, Québec, Québec (Agglomération),
>> Capitale-Nationale, Québec, G1V 1X3, Canada
>> 
>>
>> The good address is
>>
>> CFP Maurice-Barbeau
>> 920, Rue Noël-Carter, Québec, QC, G1V 5B6, Canada
>>
>> An other zip code error and an other address full of "dust".
>>
>> Every-time I tried to find something it's the same thing. It's impossible
>> to use Osmand as a GPS in Quebec City. I think it's because the data in the
>> OBF of the Province of Quebec is bad.
>>
>> Is your work have been put in the OBF? Does is exist and other OBF for
>> the Province of Quebec than the OF we can find there?
>> https://download.osmand.net/list.php
>>
>> Tank-you
>>
>>
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>


-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Question

[Pierre Béland]

Pier Luc,

Nous ne pouvons importer systématiquement dans OSM les Codes postaux, Poste 
Canada prétendant avoir un copyright la-dessus. Mais il est possible pour une 
adresse particulière (un node avec clé addr:housenumber) d'y ajouter aussi un 
code postal.  On retrouve aussi des lignes d'interpolation d'adresse. C'est de 
cette façon que OSM repère le 2985 rue de la Broussaille
voir https://www.openstreetmap.org/way/104093690Cette ligne débute au 2945
https://www.openstreetmap.org/node/1201135774et se termine au 
https://www.openstreetmap.org/node/1201130753
Si tu mettais à jour ces deux nodes en y ajoutant addr:postcode=G2C 1S1
Le bon code postal serait disponible rapidement sur le site. Par contre les 
délais de mise à jour des fichiers obf varie selon chaque éditeur de logiciel.

Une bonne façon pour toi comme collaborateur de Québec de mettre la main à la 
sauce!
Pour ce qui est des résultats lors de la recherche d'adresses, chaque logiciel 
a sa propre méthode. Et les logiciels sur téléphone ou tablette doivent 
économiser l'espace disque.  Méthode sans doute simplifiée.

Tu peux essayer le logiciel Maps.Me disponible pour Android et Apple. Et 
comparer si différent de OsmAND.
 
Pierre 
 

Le vendredi 27 avril 2018 17 h 26 min 56 s HAE, john whelan 
 a écrit :  
 
 Post codes are put in one at a time.  They aren't all there.
If you could help clean them up that would be useful.
Zip codes are different and belong in Donald's land.
Cheerio John



On Fri, 27 Apr 2018, 5:01 pm Pier Luc,  wrote:

Hello, I live in Quebec City. I tried to use OSMand (based on OSM) in my City 
using offline mode and the OBF file of the Province of Quebec. Every time I 
search an address it can not find it! Sometime it offer me other address, 
sometime not. It's like if only a tiny part of Quebec's address had been insert 
in Open Street Map. But, it's not exactly the case because is has more address 
in Open street Map website.

Look at that example, searching: 2985 rue de la Broussaille.
Osmand can't find it by OSM web site gives:
Maison 2985, Rue de la Broussaille, Neufchâtel-Est, Les Méandres, Québec, 
Québec (Agglomération), Capitale-Nationale, Québec, G2C 0G3, Canada

I think it has a problem there. A lot of information should not be there and 
the zip code is bad. It should be G2C 1S1. If that address is in the OBF, I 
supposed the app have difficulties to find it.

The good address is: 2985, Rue de la Broussaille, Québec, QC, G2C 1S1, Canada




An other test: 920, rue Noël-Carter


Osmand can't find it but OSM web site can:



École Centre de formation professionnelle Maurice-Barbeau, 920, Rue 
Noël-Carter, Sainte-Foy, Québec, Québec (Agglomération), Capitale-Nationale, 
Québec, G1V 1X3, Canada

The good address is


CFP Maurice-Barbeau
920, Rue Noël-Carter, Québec, QC, G1V 5B6, Canada

An other zip code error and an other address full of "dust".

Every-time I tried to find something it's the same thing. It's impossible to 
use Osmand as a GPS in Quebec City. I think it's because the data in the OBF of 
the Province of Quebec is bad.

Is your work have been put in the OBF? Does is exist and other OBF for the 
Province of Quebec than the OF we can find there?
https://download.osmand.net/list.php

Tank-you




   

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

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

Re: [Talk-ca] Question

[john whelan]

Post codes are put in one at a time.  They aren't all there.

If you could help clean them up that would be useful.

Zip codes are different and belong in Donald's land.

Cheerio John




On Fri, 27 Apr 2018, 5:01 pm Pier Luc,  wrote:

> Hello, I live in Quebec City. I tried to use OSMand (based on OSM) in my
> City using offline mode and the OBF file of the Province of Quebec. Every
> time I search an address it can not find it! Sometime it offer me other
> address, sometime not. It's like if only a tiny part of Quebec's address
> had been insert in Open Street Map. But, it's not exactly the case because
> is has more address in Open street Map website.
>
> Look at that example, searching: 2985 rue de la Broussaille.
> Osmand can't find it by OSM web site gives:
>
> Maison 2985, Rue de la Broussaille, Neufchâtel-Est, Les Méandres, Québec,
> Québec (Agglomération), Capitale-Nationale, Québec, G2C 0G3, Canada
> 
>
> I think it has a problem there. A lot of information should not be there
> and the zip code is bad. It should be G2C 1S1. If that address is in the
> OBF, I supposed the app have difficulties to find it.
>
> The good address is: 2985, Rue de la Broussaille, Québec, QC, G2C 1S1,
> Canada
>
>
> An other test: 920, rue Noël-Carter
>
> Osmand can't find it but OSM web site can:
>
>
> École Centre de formation professionnelle Maurice-Barbeau, 920, Rue
> Noël-Carter, Sainte-Foy, Québec, Québec (Agglomération),
> Capitale-Nationale, Québec, G1V 1X3, Canada
> 
>
> The good address is
>
> CFP Maurice-Barbeau
> 920, Rue Noël-Carter, Québec, QC, G1V 5B6, Canada
>
> An other zip code error and an other address full of "dust".
>
> Every-time I tried to find something it's the same thing. It's impossible
> to use Osmand as a GPS in Quebec City. I think it's because the data in the
> OBF of the Province of Quebec is bad.
>
> Is your work have been put in the OBF? Does is exist and other OBF for the
> Province of Quebec than the OF we can find there?
> https://download.osmand.net/list.php
>
> Tank-you
>
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Question

[Pier Luc]

Hello, I live in Quebec City. I tried to use OSMand (based on OSM) in my
City using offline mode and the OBF file of the Province of Quebec. Every
time I search an address it can not find it! Sometime it offer me other
address, sometime not. It's like if only a tiny part of Quebec's address
had been insert in Open Street Map. But, it's not exactly the case because
is has more address in Open street Map website.

Look at that example, searching: 2985 rue de la Broussaille.
Osmand can't find it by OSM web site gives:

Maison 2985, Rue de la Broussaille, Neufchâtel-Est, Les Méandres, Québec,
Québec (Agglomération), Capitale-Nationale, Québec, G2C 0G3, Canada


I think it has a problem there. A lot of information should not be there
and the zip code is bad. It should be G2C 1S1. If that address is in the
OBF, I supposed the app have difficulties to find it.

The good address is: 2985, Rue de la Broussaille, Québec, QC, G2C 1S1,
Canada


An other test: 920, rue Noël-Carter

Osmand can't find it but OSM web site can:


École Centre de formation professionnelle Maurice-Barbeau, 920, Rue
Noël-Carter, Sainte-Foy, Québec, Québec (Agglomération),
Capitale-Nationale, Québec, G1V 1X3, Canada


The good address is

CFP Maurice-Barbeau
920, Rue Noël-Carter, Québec, QC, G1V 5B6, Canada

An other zip code error and an other address full of "dust".

Every-time I tried to find something it's the same thing. It's impossible
to use Osmand as a GPS in Quebec City. I think it's because the data in the
OBF of the Province of Quebec is bad.

Is your work have been put in the OBF? Does is exist and other OBF for the
Province of Quebec than the OF we can find there?
https://download.osmand.net/list.php

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

Re: [Talk-ca] Question

[Pierre Béland]

Bonjour Pierre
Je suppose que tu parles d'un quai de pierre ou de béton.  

1. Tracer le contour du quai si non encore tracéLe quai fait partie du contour 
de la côte. Agir avec beaucoup de prudence. Souvent les contours de cours d'eau 
sont des chemins qui font partie d'une relation. Lorsque non familiers avec ces 
objets, il vaut mieux s'abtenir de modifier. Si on fait une erreur, que l'on 
laisse un polygone ouvert, alors tout le monde va crier que la terre est 
disparue, qu'il y a eu une inondation !  

Il faut en particulier faire attention aux lignes qui bordent le fleuve 
Saint-Laurent.  Le fleuve est considéré comme faisant partie des mers et on 
définit les contours avec la clé natural=coastline.  Si polygone ouvert, un 
continent complet peut disparaitre!
 Pour les rivières, nous utilisons waterway=riverbank.  Si plusieurs chemins 
sont regroupés dans une relation pour définir un long polygone, pour le fleuve 
par exemple, la clé sera dans l'objet relation et non dans l'objet chemin.
D'abord référence au cours d'eau
2.   Si le quai emprisonne une section d'eau, on peut définir la zone d'eau 
emprisonnée où les bateaux sont à quai avec la clé harbour=yes

3. Définir la zone portuaire, incluant les quais
On peut tracer un polygone par exemple qui définira la portion du quai + les 
terrains faisant partie du port et y ajouter la clé landuse=harbour pour un 
quai public ou port ou leisure=marina pour une marina. Pour un port, il faut 
évidemment connaitre la superficie de terrain occupée par le port.
Voir le Port de Montréal où j'ai plutôt utilisé landuse=industrial. 
http://www.openstreetmap.org/way/102372610

La Sémantique de OSM - La définition des clés - valeur,  évolue constamment et 
on peut parfois trouver plusieurs usages.

 


Pierre 


  De : Pierre Boucher 
 À : talk-ca@openstreetmap.org 
 Envoyé le : lundi 23 mai 2016 8h46
 Objet : [Talk-ca] Question
   
  Quel devrait être la façon de  ''tagger'' un quai public comme ceux 
rencontrés dans certains villages le long du Saint-Laurent et autres plans 
d'eau? Merci Pierre
  
 
  
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


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

[Talk-ca] Question

[Pierre Boucher]

Quel devrait être la façon de  ''tagger'' un quai public comme ceux 
rencontrés dans certains villages le long du Saint-Laurent et autres 
plans d'eau?


Merci

Pierre



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

Re: [Talk-ca] Question on CANVEC

[Adam Martin]

I agree, Harald. There are lots of things that the CANVEC adds that's
perfectly fine, if somewhat off position. Easier to edit those into
position than to try to create them whole-cloth.


On Tue, Jul 22, 2014 at 2:27 PM, Harald Kliems  wrote:

> Just to clarify, I was only talking specifically about the landuse data.
> Much of Canvec is great!
>
> Harald.
> On Jul 22, 2014 10:21 AM, "Andrew"  wrote:
>
>> I agree, that the large polygons, are a pain. I would second the
>> idea
>> of deleting and recreating the wooded areas from imagery. I don't think
>> I would go so far to say all of the canvec imported data is bad. i.e.
>> Lakes, rivers, roads, address data, train tracks, etc.
>>
>> I must from the camp where the goal is to "improve the quality of
>> the
>> map even if it is from an incremental point. (i.e. no data to some data)
>> or I guess (no data to PIA data? :-)
>>
>>
>> Andrew
>> aka CanvecImports.
>> aka I guess, one of the "offenders" :-)
>>
>>
>> On Tue, 2014-07-22 at 09:25 -0500, Harald Kliems wrote:
>> > Just delete and recreate. There have been several discussions on this
>> > list about the data quality of the landuse data and if it should've
>> > been imported in the first place (no data vs. bad data). Working with
>> > gigantic multipolygons is indeed a pain and I don't think there is any
>> > value to preserving the import data.
>> >
>> >
>> > Just my two cents,
>> >  Harald.
>> >
>> >
>> > On Tue, Jul 22, 2014 at 8:36 AM, Adam Martin 
>> > wrote:
>> > Hey all,
>> >
>> >
>> > I have a quick question on data that has been imported from
>> > CANVEC. I have been doing some work on the North-West side of
>> > Thunder Bay in Ontario. Part of that has been attempting to
>> > revamp the land use designations there. At the moment, the use
>> > has been entered via CANVEC import, but a review comparing
>> > that data to the actual land underneath from the Satellite
>> > shows fairly large variances. As well, the "Wood" polygon
>> > itself is oddly shaped, with squared lines denoting where it
>> > two CANVEC products were imported side by side.
>> >
>> >
>> > Large multi-polygon areas like these are impossible to edit in
>> > ID and still difficult in JOSM. So my question is this - if I
>> > am editing the area, what is the perception on deleting the
>> > main "Wood" polygon altogether and re-creating it? My intent
>> > would be to increase the accuracy of the map in the area based
>> > on the satellite data provided by Bing and this would be
>> > easier if the land use were cleared and re-built. I would
>> > leave the features that CANVEC imported - only the land use
>> > would be re-constructed in that case. The other components
>> > would simply be moved and edited as needed.
>> >
>> >
>> > Thanks,
>> >
>> >
>> > Adam
>> >
>> >
>> > ___
>> > Talk-ca mailing list
>> > Talk-ca@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-ca
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Please use encrypted communication whenever possible!
>> > Key-ID: 0x34cb93972f186565
>> > ___
>> > Talk-ca mailing list
>> > Talk-ca@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Question on CANVEC

[Harald Kliems]

Just to clarify, I was only talking specifically about the landuse data.
Much of Canvec is great!

Harald.
On Jul 22, 2014 10:21 AM, "Andrew"  wrote:

> I agree, that the large polygons, are a pain. I would second the
> idea
> of deleting and recreating the wooded areas from imagery. I don't think
> I would go so far to say all of the canvec imported data is bad. i.e.
> Lakes, rivers, roads, address data, train tracks, etc.
>
> I must from the camp where the goal is to "improve the quality of
> the
> map even if it is from an incremental point. (i.e. no data to some data)
> or I guess (no data to PIA data? :-)
>
>
> Andrew
> aka CanvecImports.
> aka I guess, one of the "offenders" :-)
>
>
> On Tue, 2014-07-22 at 09:25 -0500, Harald Kliems wrote:
> > Just delete and recreate. There have been several discussions on this
> > list about the data quality of the landuse data and if it should've
> > been imported in the first place (no data vs. bad data). Working with
> > gigantic multipolygons is indeed a pain and I don't think there is any
> > value to preserving the import data.
> >
> >
> > Just my two cents,
> >  Harald.
> >
> >
> > On Tue, Jul 22, 2014 at 8:36 AM, Adam Martin 
> > wrote:
> > Hey all,
> >
> >
> > I have a quick question on data that has been imported from
> > CANVEC. I have been doing some work on the North-West side of
> > Thunder Bay in Ontario. Part of that has been attempting to
> > revamp the land use designations there. At the moment, the use
> > has been entered via CANVEC import, but a review comparing
> > that data to the actual land underneath from the Satellite
> > shows fairly large variances. As well, the "Wood" polygon
> > itself is oddly shaped, with squared lines denoting where it
> > two CANVEC products were imported side by side.
> >
> >
> > Large multi-polygon areas like these are impossible to edit in
> > ID and still difficult in JOSM. So my question is this - if I
> > am editing the area, what is the perception on deleting the
> > main "Wood" polygon altogether and re-creating it? My intent
> > would be to increase the accuracy of the map in the area based
> > on the satellite data provided by Bing and this would be
> > easier if the land use were cleared and re-built. I would
> > leave the features that CANVEC imported - only the land use
> > would be re-constructed in that case. The other components
> > would simply be moved and edited as needed.
> >
> >
> > Thanks,
> >
> >
> > Adam
> >
> >
> > ___
> > Talk-ca mailing list
> > Talk-ca@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ca
> >
> >
> >
> >
> >
> > --
> > Please use encrypted communication whenever possible!
> > Key-ID: 0x34cb93972f186565
> > ___
> > Talk-ca mailing list
> > Talk-ca@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Question on CANVEC

[Andrew]

I agree, that the large polygons, are a pain. I would second the idea
of deleting and recreating the wooded areas from imagery. I don't think
I would go so far to say all of the canvec imported data is bad. i.e.
Lakes, rivers, roads, address data, train tracks, etc.

I must from the camp where the goal is to "improve the quality of the
map even if it is from an incremental point. (i.e. no data to some data)
or I guess (no data to PIA data? :-)


Andrew
aka CanvecImports.
aka I guess, one of the "offenders" :-)


On Tue, 2014-07-22 at 09:25 -0500, Harald Kliems wrote:
> Just delete and recreate. There have been several discussions on this
> list about the data quality of the landuse data and if it should've
> been imported in the first place (no data vs. bad data). Working with
> gigantic multipolygons is indeed a pain and I don't think there is any
> value to preserving the import data. 
> 
> 
> Just my two cents,
>  Harald.
> 
> 
> On Tue, Jul 22, 2014 at 8:36 AM, Adam Martin 
> wrote:
> Hey all,
> 
> 
> I have a quick question on data that has been imported from
> CANVEC. I have been doing some work on the North-West side of
> Thunder Bay in Ontario. Part of that has been attempting to
> revamp the land use designations there. At the moment, the use
> has been entered via CANVEC import, but a review comparing
> that data to the actual land underneath from the Satellite
> shows fairly large variances. As well, the "Wood" polygon
> itself is oddly shaped, with squared lines denoting where it
> two CANVEC products were imported side by side.
> 
> 
> Large multi-polygon areas like these are impossible to edit in
> ID and still difficult in JOSM. So my question is this - if I
> am editing the area, what is the perception on deleting the
> main "Wood" polygon altogether and re-creating it? My intent
> would be to increase the accuracy of the map in the area based
> on the satellite data provided by Bing and this would be
> easier if the land use were cleared and re-built. I would
> leave the features that CANVEC imported - only the land use
> would be re-constructed in that case. The other components
> would simply be moved and edited as needed.
> 
> 
> Thanks,
> 
> 
> Adam
> 
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
> 
> 
> 
> 
> 
> -- 
> Please use encrypted communication whenever possible!
> Key-ID: 0x34cb93972f186565
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca



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

Re: [Talk-ca] Question on CANVEC

[Harald Kliems]

Just delete and recreate. There have been several discussions on this list
about the data quality of the landuse data and if it should've been
imported in the first place (no data vs. bad data). Working with gigantic
multipolygons is indeed a pain and I don't think there is any value to
preserving the import data.

Just my two cents,
 Harald.


On Tue, Jul 22, 2014 at 8:36 AM, Adam Martin 
wrote:

> Hey all,
>
> I have a quick question on data that has been imported from CANVEC. I have
> been doing some work on the North-West side of Thunder Bay in Ontario. Part
> of that has been attempting to revamp the land use designations there. At
> the moment, the use has been entered via CANVEC import, but a review
> comparing that data to the actual land underneath from the Satellite shows
> fairly large variances. As well, the "Wood" polygon itself is oddly shaped,
> with squared lines denoting where it two CANVEC products were imported side
> by side.
>
> Large multi-polygon areas like these are impossible to edit in ID and
> still difficult in JOSM. So my question is this - if I am editing the area,
> what is the perception on deleting the main "Wood" polygon altogether and
> re-creating it? My intent would be to increase the accuracy of the map in
> the area based on the satellite data provided by Bing and this would be
> easier if the land use were cleared and re-built. I would leave the
> features that CANVEC imported - only the land use would be re-constructed
> in that case. The other components would simply be moved and edited as
> needed.
>
> Thanks,
>
> Adam
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>


-- 
Please use encrypted communication whenever possible!
Key-ID: 0x34cb93972f186565
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Question on CANVEC

[Adam Martin]

Hey all,

I have a quick question on data that has been imported from CANVEC. I have
been doing some work on the North-West side of Thunder Bay in Ontario. Part
of that has been attempting to revamp the land use designations there. At
the moment, the use has been entered via CANVEC import, but a review
comparing that data to the actual land underneath from the Satellite shows
fairly large variances. As well, the "Wood" polygon itself is oddly shaped,
with squared lines denoting where it two CANVEC products were imported side
by side.

Large multi-polygon areas like these are impossible to edit in ID and still
difficult in JOSM. So my question is this - if I am editing the area, what
is the perception on deleting the main "Wood" polygon altogether and
re-creating it? My intent would be to increase the accuracy of the map in
the area based on the satellite data provided by Bing and this would be
easier if the land use were cleared and re-built. I would leave the
features that CANVEC imported - only the land use would be re-constructed
in that case. The other components would simply be moved and edited as
needed.

Thanks,

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

Re: [Talk-ca] Question?

[Paul Norman]

This is not correct – there are no mandatory tags, and there is no legal reason 
why a source tag can’t be removed. Incidentally, source tags are perhaps the 
ones most frequently removed as osm2pgsql drops them by default.

 

If you’re looking at doing an import 
http://wiki.openstreetmap.org/wiki/Import/Guidelines is what you need to read. 
It’s important to note the requirement to consult with both the talk-ca@ and 
the imports@ mailing lists. This is important because it means if you missed 
something else someone else might spot it.

 

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: Monday, April 22, 2013 6:55 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Question?

 

*   It is mandatory to  mention origin and milesim of Opendata, within a 
tag, for instance "Direction générale des finances publiques - année 2008". 

Source = 
http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Conditions_d%27utilisation

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

[Talk-ca] Question?

[Bruno Remy]

(English message will follow)

Bonjour à tous! :-)

Toujours à propos du débat sur les licences, des faits rééls de deux cas de
licence ouverte permettent d'établir les points suivants:
- Depuis 2009 déjà, la DGFiP (Direction générale des finances publiques) en
charge du cadastre en ligne autorise OpenStreetMap et ses contributeurs à
utiliser les données cadastrales

1/Il y a deux conditions à la réutilisation des données du cadastre:

   - la réutilisation des données doit former un travail composite. Les
   données du cadastre ne peuvent former *à elles seules* les données OSM.
   - Il est obligatoire d'indiquer l'origine et le millésime des données
   avec un tag source, par exemple "Direction générale des finances publiques
   - année 2008".

Source =
http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Conditions_d%27utilisation


2/Le Gouvernement français publie ses données ouvertes sous les termes de
la "Licence Ouverte" et des données protégées par cette licences ont fait
l'objet d'imports massifs dans OSM.
Source=
http://www.etalab.gouv.fr/pages/Licence_ouverte_Open_licence-5899923.html

Donc ces faits parlent d'eux mêmes et induisent la logique suivante:

SI {
(la licence est ODBL)
OU
(la licence est NON-ODBL ET  fait l'objet d'accord écrits de la part du
publicateur des données)
OU
(la licence est LO "Licence Ouverte")
}
ET
Il y a eu un consensus au sein de notre communauté OSM-CA
ALORS
Les données pourraient possiblement être importées .


Est-ce bien cela?



Hi there ! :-)

Still about licences : some facts about two uses of OpenData gives the
following statements:

1/Since 2009 , la DGFiP (French Financial Dept.) in charge of "cadastre"
authorized OpenStreetMap & contributors to use their cadastral opendata.

But exlcusively with two major conditions:

   - the use of cadastral must be a composit work. This means that OSM
   data  cadastre ne peuvent former *could'nt only consist of *Cadastral
   data.
   - It is mandatory to  mention origin and milesim of Opendata, within a
   tag, for instance "Direction générale des finances publiques - année 2008".

Source =
http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Conditions_d%27utilisation


2/ French gouverment has a web-portal with the "OL" licence (Open Licence),
and some data protected by this licence has been the source of
massive-imports into the OpenStreetMap's database.

Source=
http://www.etalab.gouv.fr/pages/Licence_ouverte_Open_licence-5899923.html

So, those facts talk themself and lead to the following logic statement:

IF {
( licence is ODBL)
OR
(licence is NOT ODBL BUT has been the object of an official term-of-use
formally given by the provider of OpenData)
OR
(licence est OL "Open-Licence")
}
AND
A census has been settled within our OSM-CA community
}
THEN
Data may perhaps be imported  .

Is that right? Or?

Best regards,



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

Re: [Talk-ca] Question re mapping parties and geobase upload

[Michael Barabanov]

Agreed on all points.  I'd still encourage to do GeoBase import ASAP,
though.  Most of the labor with importing Geobase is sorting out the overlaps
between existing OSM and GeoBase data.  For one thing, RoadMatcher does
not always find all matching roads.  Also, topological problems are guaranteed 
to 
happen where two datasets meet because we're favoring OSM data. These need to 
be fixed
for routing to work (but can be done after the import).  
So the net effect is that the more OSM street data there is, the more
conflicts there will be to fix during the import and after.

This is absolutely not to discourage OSM mapping; I'm just sharing my
observations from doing an import. Also note that this only applies to streets.
As Richard mentioned, there are plenty of other things to map!
I'm finding I'm having much easier time mapping these other features now that I
have the base NRN data in place for the area.

Michael.

On Tue, Jun 02, 2009 at 03:27:49PM -0400, Richard Weait (rich...@weait.com) 
wrote:
> On Tue, 2009-06-02 at 14:54 -0400, Pagurek,Debbie [NCR] wrote:
> > Hi all, 
> > I am new to OpenStreetMap. I am happy to hear about the announcement
> > about the inclusion of GeoBase data in OSM. I am currently writing an
> > internal newsletter for my organization, with an article featuring
> > OSM. My question is this - in light of GeoBase data being included,
> > should I be encouraging people to get out there to do mapping parties?
> > Or should I instead tell them how to get involved in uploading areas
> > from Geobase? If people go out to do mapping parties and then the
> > GeoBase data is uploaded to the same area, what happens to their
> > mapping party data?
> 
> Hi Debbie, 
> 
> Welcome to you and to your organization.  
> 
> Yes!  Absolutely you should get out and participate by mapping and
> hosting mapping parties and learning about the tools and projects in and
> around OpenStreetMap.  If you look at the OpenStreetMap slogan [1] "It's
> fun.  It's free.  You can help."  All of that is true when considering
> the imported data.  
> 
> Firstly, you will participate in OSM because it is fun.  If it is useful
> to you or your organization that's great too, but you'll keep
> participating because it is fun.  
> 
> It's free and the GeoBase and other data sets [2] are included because
> they can be included without detracting from your freedom to you the
> data and the rest of the OpenStreetMap project.  
> 
> And you can help.  The governments of Canada (federal, provincial,
> regional) can not map everything that we can map as OpenStreetMap
> contributors.  We, as contributors, have diverse interests and we live
> and work everywhere we can accomplish mapping tasks that "The
> Government" can't or won't map.  We as citizens would flip out if the
> government compiled a map of Canadian coffee shops and bowling alleys.  
> 
> We can do it for fun.  So why not add the local bowling alleys and
> coffee shops that you know to the map?  
> 
> How does the import effect your mapping parties and your collected data?
> The import team is deliberately avoiding the destruction of user
> contributed data.  The process may not be perfect but we are using tools
> that allow us to recognize GeoBase data that already has already been
> contributed by a user, and preferentially leaving that user contributed
> data in place.  
> 
> Also, there are many things that you can add to the map that do not
> appear in the GeoBase or other data sets.  Things like recreation trails
> and facilities, businesses, historic and tourism points of interest.  
> 
> We're having a mapping party in Toronto on Sunday, 07 June 2009 and you
> should join us.  [3]  
> 
> Best regards,
> Richard
> 
> [1] http://wiki.openstreetmap.org/wiki/Banner
> [2] http://wiki.openstreetmap.org/wiki/Attribution
> [3] http://www.meetup.com/OpenStreetMap-Toronto/calendar/10345433/
> 
> 
> 
> ___
> 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] Question re mapping parties and geobase upload

[Richard Weait]

On Tue, 2009-06-02 at 14:54 -0400, Pagurek,Debbie [NCR] wrote:
> Hi all, 
> I am new to OpenStreetMap. I am happy to hear about the announcement
> about the inclusion of GeoBase data in OSM. I am currently writing an
> internal newsletter for my organization, with an article featuring
> OSM. My question is this - in light of GeoBase data being included,
> should I be encouraging people to get out there to do mapping parties?
> Or should I instead tell them how to get involved in uploading areas
> from Geobase? If people go out to do mapping parties and then the
> GeoBase data is uploaded to the same area, what happens to their
> mapping party data?

Hi Debbie, 

Welcome to you and to your organization.  

Yes!  Absolutely you should get out and participate by mapping and
hosting mapping parties and learning about the tools and projects in and
around OpenStreetMap.  If you look at the OpenStreetMap slogan [1] "It's
fun.  It's free.  You can help."  All of that is true when considering
the imported data.  

Firstly, you will participate in OSM because it is fun.  If it is useful
to you or your organization that's great too, but you'll keep
participating because it is fun.  

It's free and the GeoBase and other data sets [2] are included because
they can be included without detracting from your freedom to you the
data and the rest of the OpenStreetMap project.  

And you can help.  The governments of Canada (federal, provincial,
regional) can not map everything that we can map as OpenStreetMap
contributors.  We, as contributors, have diverse interests and we live
and work everywhere we can accomplish mapping tasks that "The
Government" can't or won't map.  We as citizens would flip out if the
government compiled a map of Canadian coffee shops and bowling alleys.  

We can do it for fun.  So why not add the local bowling alleys and
coffee shops that you know to the map?  

How does the import effect your mapping parties and your collected data?
The import team is deliberately avoiding the destruction of user
contributed data.  The process may not be perfect but we are using tools
that allow us to recognize GeoBase data that already has already been
contributed by a user, and preferentially leaving that user contributed
data in place.  

Also, there are many things that you can add to the map that do not
appear in the GeoBase or other data sets.  Things like recreation trails
and facilities, businesses, historic and tourism points of interest.  

We're having a mapping party in Toronto on Sunday, 07 June 2009 and you
should join us.  [3]  

Best regards,
Richard

[1] http://wiki.openstreetmap.org/wiki/Banner
[2] http://wiki.openstreetmap.org/wiki/Attribution
[3] http://www.meetup.com/OpenStreetMap-Toronto/calendar/10345433/



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

[Talk-ca] Question re mapping parties and geobase upload

[Pagurek,Debbie [NCR]]

Hi all,
I am new to OpenStreetMap. I am happy to hear about the announcement
about the inclusion of GeoBase data in OSM. I am currently writing an
internal newsletter for my organization, with an article featuring OSM.
My question is this - in light of GeoBase data being included, should I
be encouraging people to get out there to do mapping parties? Or should
I instead tell them how to get involved in uploading areas from Geobase?
If people go out to do mapping parties and then the GeoBase data is
uploaded to the same area, what happens to their mapping party data?

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

Re: [Talk-ca] Question about NIDs

[Steve Singer]

On Wed, 21 Jan 2009, Richard Degelder wrote:

> The other option is to take the longer ways and have a relationship
> attributed to the appropriate section which will have the NID.  This
> would likely not be frequently disturbed by new editors to the map, but
> the need for making this automatic in some way will make the script a
> lot more complex.  And we are going to have to find a way to combine the
> short ways generated by Steve's scripts into a longer way and that
> represent the entire roadway.

The relationship between OSM ways and GeoBase segments is a many to many 
relationship.

The methods that I've come across for representing this in the OSM data model 
are

1) Split the OSM ways to the smallest common components (This is how we 
imported Fort McMurray, and seems to be the generally accepted solution to 
dealing with this type of thing in OSM today).

2) See http://wiki.openstreetmap.org/wiki/Relations/Proposed/Segmented_Tag
This proposed scheme would allow a relation to point to the start/end of
the portion way a osm way that the geobase uuid applies to.

3) Create a second ways that don't get rendered but shares the same nodes. 
You would then need to  associate these child ways to the parent through 
some method.  (I'm not a big fan of this)


> The script could be as simple as looking for intersections and dividing
> ways whenever it encounters one.  The end result would be a tremendous
> number of ways within Canada, I would be curious as to how many
> roadsegments are within GeoBase, and it would have to be rerun prior to
> any updates from GeoBase being applied to OSM to catch new user entered
> data, but it would match what GeoBase looks like.  Then running
> RoadMatcher against the results and have the pertinent data from GeoBase
> imported to the new OSM ways.

Ontario, BC, Alberta and The Yukon combined have about 1.1 million road 
segments in the NRN (those are the only datasets I have loaded).

> effected by it as opposed to a long way, or a section of it.  The other
> alternative is to get a better understanding of how to generate a script
> that will create relationships within longer ways and retain the long
> ways but still include the GeoBase NIDs for the appropriate sections

Modifying geobase2osm.py to merge adjoining ways if they share the same 
name, (and maybe # of lanes) would not be hard.  It could create the 
relation for Segmented ways as well.  However I wouldn't want to start bulk 
importing data that uses a tagging scheme that hasn't been approved where 
there is already a generally accepted method of doing this (splitting the 
ways)


> Richard Degelder
>
>

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

Re: [Talk-ca] Question about NIDs

[Sam Vekemans]

>
> Sam, can you describe to me the steps taken to be able to copy a
>
node/way from one layer to another in JOSM? I've asked a couple times,

and no one has been able to tell me how to accomplish this task. The

closest answer so far has been to merge both layers.


BTW, how come sometimes the OSM download gets pulled in as a new

layer, and sometimes it ends up merged into the existing layer?


James

VE6SRV


Maybe, :)
In JOSM when you go to download new OSM data, there is a a few check boxes
above where the option is to paste in the url link of where you want to grab
the data from.
""Data Sources and Types
-openstreetmap data
-Raw GPS data
-download as a new layer. (uncheck or check that box) if your dealing with
geobase.osm, you want to have the OSM data downloaded as a new layer. ..
this avoids accidental duplicate uploads of a big area.

(It's a good idea to get the latest version of JOSM, as more bugs have been
fixed.)

...instead of merging this is working in the finer details..

1 - select the GeoBase.OSM file layer.
2 - select all the ways that you want to import (zoom in to get as close as
possible) (only do a few at a time)
3 - select edit/copy
4 - select away from the selection
5 - select the Data Layer (OSM data)
6 - select edit/paste
7 - move the new copy into position
8 - review what it looks like
8 - upload the changes to OSM

The pasted way will show up a slight distance away from the origional (on
the other layer), you just need to drag the way into the right position.

Having the GPX layer also downloaded will help in aligning it.

This copies ALL of the tags on ALL of the ways/nodes selected.

Hope that helps.

Cheers,
Sam

P.S.
On Saturday noon PST i'll see if i can book the room again, as it might be
worthwhile having a video conference.  Questions can be answered instantly
as apposed to waiting for the email.
I do have a rebuttal for Richard, just need to think it over 1st :)
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Question about NIDs

[Richard Degelder]

On Wed, 2009-01-21 at 12:26 -0800, Sam Vekemans wrote:
> Hi all,
> Here's IMO, based on the last digest.
> I tried to cover that with my video conference trial-run, and got
> stuck.
> 
> 
> Lets look at the facts.
> The RoadMatcher script AFAIK does NOT actually look at the NID when
> looking at existing OSM data and deciding on weather or not it should
> be added. ... is this true?
> 

True, the RoadMatcher application does not look at any of the attributes
of the OSM way or the GeoBase Roadsegment.  What it looks for is the
location of nodes that define a roadway, an it does so with a bit of
leeway so if the nodes in the OSM way and GeoBase Roadsegment are not in
the exact same place but are close it will say that they represent the
same node.  It also does not require the same number of nodes, or in the
same place, as long as the basic profile of the roadway within OSM and
GeoBase match RoadMatcher considers it a match.

> 
> For updates, the road matcher script can be used, and looks at all the
> OSM data (imported & existing) and treats the existing AS IF if were
> OSM created. It only looks at its  coordinates, the osm roadtype &
> road name tags.
> 

Roadmatcher looks for the roadways to match and really never considers
the extra data, such as road name, number of lanes, GeoBase NID, etc,
that goes along with it.  That is all meta data, something that is
important but not for the function of RoadMatcher.

So sure RoadMatcher can be used during an update but I doubt that it
will be the prime tool for the update.  It will be used to locate
roadways that are added, and by extension compare the current OSM data
against the GeoBase file, or GeoBase update file probably, to the OSM
since the last update/import.  In this respect it will be used in much
the same way it is right now, although there will be much more OSM data
to look at and there will be very few new roadways that are not going to
be matched between the OSM file and the GeoBase update.

For updating things like street names where they are not available, but
we have imported the GeoBase NIDs into OSM, it is likely easier to write
a new script that creates a new attribute, and possibly checks for one
first, with the appropriate data for that NID.  It can be a simple
search that looks for an NID and then, after ensuring that the data does
not already exist, inserts a new attribute for that way.

> 
> For situations where road matcher got flustered and didnt import the
> road, but should have.  This is why the origional import file is made
> available to use;
>   We can load the GeobaseOrigional file, and compare it with existing
> data. ... just by having (in JOSM) both layers on, (with GeoBase as
> the shadded one) you can pan around the area your working on and right
> away see what needs to be added.   You then just select those items,
> then copy. .. then hide that layer, then paste on the osm layer. then
> upload changes.
> 

Steve made the original import file with all of the roadways, both those
matched and those that are standalone, available not so much to use for
adding the roadways that are not currently within OSM but for a
reference.  There is really no reason for the complete file to be made
available or to be used for the update/import.  Once we are comfortable
with the process the only files that are going to be needed are the
standalone file since it has all of the required changes.  The
standalone file may, on occasion, miss a street that should be in it
because it is not already represented within OSM but that is a minor
inconvenience, especially since there are really very few of them.  In
fact, while doing some testing, I found that there are more roadways
that are in neither OSM nor GeoBase because the streets are too new to
have had a chance to propagate through the system to already be in
GeoBase, than were missing from the standalone file that should have
been there.  There are also more streets within OSM that are not yet
available within GeoBase as well.

As for the technique you describe for using JOSM the file you should be
using is the standalone file that Steve creates.  Your technique is good
if you were to want to manually import the GeoBase data.  But Steve
takes the standalone file and imports it directly into OSM so at that
point all of the current OSM data and the new GeoBase data are together
within OSM.  You are very unlikely to find anything that was missed.

As Steve becomes more proficient at tuning, and to a degree
understanding, RoadMatcher he is going to be able to have it get better
at finding all of the missing roadways from OSM, that do already exist
within GeoBase, without having any duplicates and then have them
imported into OS with another script.  At this point, and Fort McMurray
was really test case because it is fairly small and has a single person
who has uploaded the vast majority of the data and is willing to
experiment with the import, we are still finding what it will take to
make RoadM

Re: [Talk-ca] Question about NIDs

[James Ewen]

On Wed, Jan 21, 2009 at 1:26 PM, Sam Vekemans
 wrote:
> Hi all,

>   We can load the GeobaseOrigional file, and compare it with existing data.
> ... just by having (in JOSM) both layers on, (with GeoBase as the shadded
> one) you can pan around the area your working on and right away see what
> needs to be added.   You then just select those items, then copy. .. then
> hide that layer, then paste on the osm layer. then upload changes.

Sam, can you describe to me the steps taken to be able to copy a
node/way from one layer to another in JOSM? I've asked a couple times,
and no one has been able to tell me how to accomplish this task. The
closest answer so far has been to merge both layers.

BTW, how come sometimes the OSM download gets pulled in as a new
layer, and sometimes it ends up merged into the existing layer?

James
VE6SRV

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

Re: [Talk-ca] Question about NIDs

[Sam Vekemans]

Hi all,Here's IMO, based on the last digest.
I tried to cover that with my video conference trial-run, and got stuck.

Lets look at the facts.
The RoadMatcher script AFAIK does NOT actually look at the NID when looking
at existing OSM data and deciding on weather or not it should be added. ...
is this true?

For updates, the road matcher script can be used, and looks at all the OSM
data (imported & existing) and treats the existing AS IF if were OSM
created. It only looks at its  coordinates, the osm roadtype & road name
tags.

For situations where road matcher got flustered and didnt import the road,
but should have.  This is why the origional import file is made available to
use;
  We can load the GeobaseOrigional file, and compare it with existing data.
... just by having (in JOSM) both layers on, (with GeoBase as the shadded
one) you can pan around the area your working on and right away see what
needs to be added.   You then just select those items, then copy. .. then
hide that layer, then paste on the osm layer. then upload changes.

So this has nothing todo with the NIDs.  ... NID's are only there for making
that 1st conversion, when running the script to make the OSM file.  ... once
it's and OSM file, it's the OSM tags that are relevant.

Re:  pieces of ways in a line

Because it's only the geobase ways that are not already in OSM that we are
dealing with, it would be fine to be joining the ways as longer road
segments.   ... this is conforming to OSM standards.

OSM does NOT need to conform to GeoBase standards at all.  This is a one-way
import.

Conclusion:

For updates, because AFAICT the script looks at it's 1 - relative
coordinates, 2 - road name and 3 -road type to see a match.   There is no
way that it can create a new NID for existing ways, then compare that.  The
would be illogical.

For future post-codes import;
The script would need to look up the relative coordinates, road name, road
type and add in this feature as a NODE.
If the post-codes are available the as polygons, then GREAT the polygons
would be able to be imported with no interference... the borders of the
polygon would be boundary lines anyway (not roads)

For future house-numbers
The best way to deal with it, is to import it as nodes. .. and if the node
doesnt line up with the road. .. no big deal... as long as it's tagged
right, the search engine should be able to pick it up.

For road names:
I think that Roadmatcher would be able to pick it up, as people could be
importing the roads (of Ontario) without names. ... but we EXPECT or HOPE
that those who import data, ONLY import the roads that they intend on adding
the NAME tag. .. so the script should have no problem looking at it, so
where the road name was spelled differently.  The OSM version would Trump
it.  ... no NID's would need to be added to OSM data.

Hope this makes sense,  (had to sleep on it) :-)

Cheers,
Sam Vekemans
Across Canada Trails
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Question about NIDs

[Steve Singer]

On Tue, 20 Jan 2009, James Ewen wrote:

> On Tue, Jan 20, 2009 at 6:01 PM,   wrote:
>
> What I would like to do, is be able to delete all of my OSM ways, and
> replace them with the GeoBase data. From there I would then use the
> GPX tracks that I have collected as a basis to modify the GeoBase
> data, so that it represents the real world data more accurately.

Scripting a bulk deleting all the nodes in an area that meet various 
criteria is quite doable.  The harder question is what criteria do you use? 
>From a technical standpoint this would be a lot easier to implement if you 
didn't need to look at the object edit history when deciding which nodes 
should be deleted (ie not restrict things to just nodes only edited by 
'VE6SRV').

I'd also prefer doing this step before the bulk import vs after because 
it saves a second import step.  Also the current scripts won't connect 
intersections across two import cycles (scripts to do this could be 
written, but they haven't yet).

> Here's another example where I can see being able to manually remove
> old OSM data, and replacing it with GeoBase data. Most of the primary
> highway grid that exists in Alberta was traced from Landsat data, if
> I'm not mistaken. Whatever the source, the existing road data is of
> very poor accuracy.  Steve's road matcher is going to have a horrid
> time trying to match the GeoBase roads against the existing OSM roads
> which can be upwards of 1/2 a mile out of place. I doubt that I would
> find anyone that object to removing the crude existing OSM data in
> favour of the GeoBase data.
>
> An easy solution would be to delete all the crude highway data, and
> then run Steve's script against a blank slate. However, this means
> that someone will have to go through the OSM map before running the
> script to remove the crude data.

If you had some why of identifying the data (ie any high tagged a 
'Hwy 16' you could do a bulk delete.  You can play around with 
http://wiki.openstreetmap.org/wiki/Osmxapi to see how well this works 
(finding these highways by query).

Another option is for people to manually collect the list of OSM way id's 
that we would want to bulk delete as part of the import.  We'd have to come 
to some decision on how we decide which highways are 'crude' and need bulk 
deletion.


>
> I have tracked a number of major highways across Alberta, into BC, and
> also Saskatchewan and used that to replace the crude older highway
> data. Steve's roadmatcher script will probably have an easier time
> matching to those ways, but that still leaves thousands of miles of
> highway that will need to be manually stitched to the GeoBase data.
> Again, I think it would be much faster to modify the GeoBase data to
> match the GPX tracks if need be, rather than manually match the OSM
> ways against the GeoBase data.
>
> Anyone else have any observations or opinions?
>
> James
> VE6SRV
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>


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

Re: [Talk-ca] Question about NIDs

[Richard Degelder]

On Wed, 2009-01-21 at 01:01 +, michc...@gmail.com wrote:
> On Jan 20, 2009 12:48am, James Ewen  wrote:
> > On Mon, Jan 19, 2009 at 6:53 PM, Richard Degelder
> rtdegel...@gmail.com> wrote:
> > 
> > 
> > 
> > > Is there a process to include the NID, in an
> > 
> > > appropriate manner, with the import data that was derived from
> GeoBase?
> > 
> > 
> > 
> > In Steve's upload, we have a UUID with each element. I believe that
> is the NID.
> > 
> > 
> > 
> > geobase:uuid f722391f5b5d4eb1877a24fd69365ff8
> > 
> > 

Yes that should be the NID, it is 32 characters long.

> > 
> > > And has there been any considerations as to how to add the NID
> > 
> > > attributes to those ways already within OSM?
> > 
> > 
> > 
> > That, I'm not sure how to handle, especially when the OSM nodes and
> > 
> > ways won't match up with the GeoBase nodes and ways. How would you
> > 
> > match them when there may be 3 OSM nodes and only 2 GeoBase nodes,
> or
> > 
> > more likely 6 GeoBase ways making up a roadway that is defined by
> only
> > 
> > one OSM way.
> > 
> > 

Apparently the number of nodes within the OSM way and the GeoBase
Roadsegment do not have to match, or even be close to matching, in
numbers.  As long as the RoadMatcher application can determine that
there is enough similarities between the two sources, and they are
within a specific tolerance, then RoadMatcher will claim that they
represent the same roadway.

And Roadmatcher is also able to determine that multiple roadsegments
within GeoBase are being represented within a single way that covers the
same area.  RoadMatcher is, apparently, looking for where the ends of
the GeoBase roadsegment and OSM way align and counts it as a match.

> It is not a simple issue. I see 2 options: the first one is to align
> the osm geometry with the nrn-geobase geometry (or the opposite), then
> add the NIDs. At this stage, I wonder if we should take Geobase
> geometry and join the osm attributes. The second option is to use NIDs
> only for the nrn-geobase imported in osm.
> 

For the two options you suggest we are going to have to in some manner
align the two data sets.  As for using only, or largely, the GeoBase
data and assigning the OSM attributes we are then going to be replacing
all of the user entered data and replacing it with GeoBase data.  Doing
this would go against one of the goals of trying to retain the user
generated data within OSM.  And even then we are going to have to find a
way to match the two data sets to be able to transfer the OSM
attributes.

As for using the NIDs only on the GeoBase derived data it would make the
ideas of updating the map in the future impossible.  At that point
adding the NIDs to even the GeoBase derived import is a waste of time.

With the import of the GeoBase data for Fort McMurray Steve made each
GeoBase Roadsegment into a separate way.  So a street that had five
blocks, and so five separate NIDs, was entered onto the map as five
separate ways in OSM.  Is that what we want for the future?

This would make it imperative that the renderers are able to determine
that these separate ways should be presented as a single street rather
than attempting to present the street name on each section.  In most
cases the renderers do that very well but at a certain level of
magnification they start to break down and present each section with its
own name.  Another issue will be when someone attempts to combine these
short ways into a longer way to represent the entire roadway in one
piece.

The other option is to take the longer ways and have a relationship
attributed to the appropriate section which will have the NID.  This
would likely not be frequently disturbed by new editors to the map, but
the need for making this automatic in some way will make the script a
lot more complex.  And we are going to have to find a way to combine the
short ways generated by Steve's scripts into a longer way and that
represent the entire roadway.

Steve, with RoadMatcher, already is able to determine that a way, or
even a portion of an OSM way, matches a roadsegment from GeoBase.  At
this point the only question is how do we create the tag data for the
way.

The real question, to some degree, is what do we do with the existing
data within OSM.  If we want to retain the user generated data and we
want to have one of the attributes to be the proper NID do we find a way
to create a script that will generate a relationship for that portion of
the way and then assign the NID as a tag for that relationship?  Or do
we create a script that will look for intersections and ends of roads
and breaks up ways in the same location as GeoBase already has?

Running a script that will divide up current OSM ways into sections that
match the GeoBase NID is not destroying user entered data.  It is a
modification, and it is being done with a script rather than a person,
but it is really not a lot different then someone modifying data that I
had originally entered.

The script could b

Re: [Talk-ca] Question about NIDs

[Michel Gilbert]

2009/1/20 James Ewen 

> On Tue, Jan 20, 2009 at 6:01 PM,   wrote:
>
> > It is not a simple issue. I see 2 options: the first one is to align the
> osm
> > geometry with the nrn-geobase geometry (or the opposite), then add the
> NIDs.
> > At this stage, I wonder if we should take Geobase geometry and join the
> osm
> > attributes. The second option is to use NIDs only for the nrn-geobase
> > imported in osm.
>
> I'm kind of stuck, and I'm not sure where to go from here.
>
> I have invested quite a bit of time and effort collecting, importing,
> and converting GPS tracks in Fort McMurray. Steve's GeoBase import
> script has done a very good job adding GeoBase data all around my data
> that I had already put into the OSM database.
>
> Now I need to spend time making the OSM and GeoBase data integrate
> together. I can add nodes that correspond to GeoBase nodes, and make
> my OSM ways connect to these points. I can attempt to make all of my
> ways correspond to GeoBase data, but that is a lot of work, especially
> trying to put all the attributes onto each and every one of these
> nodes and ways.


Your approach is the option 2 that I have mentioned. My favorite one too :
import nrn-geobase to complete exsiting osm then integrate it to existing
osm. The option 1 is my view if we wanted to have Geobase NID to existing
osm.

>
>
> What I would like to do, is be able to delete all of my OSM ways, and
> replace them with the GeoBase data. From there I would then use the
> GPX tracks that I have collected as a basis to modify the GeoBase
> data, so that it represents the real world data more accurately.
>
> It just seems to me that my time and efforts would be better invested
> by making minor modifications to the GeoBase data to align with my
> observations rather than attempting to make major modifications to my
> OSM data to align with the GeoBase data.
>
> Don't get me wrong, the GeoBase imported data in the Fort McMurray
> area is a good thing in my opinion. I also agree that the GeoBase
> update should not automatically overwrite user entered OSM data. What
> I am looking for is a way to be able to manually replace my existing
> OSM data with GeoBase data, but only at a specific user request, be it
> mine or someone else working in an area of their concern.


I noticed the same kind of examples. Sometimes, osm ways are not accurate or
badly captured. RoadMatcher does not work well for these cases. So to detect
them you have to do it manually and change them by nrn-geobase data. We
can't make the whole country like that. It makes the job harder but it price
to pay to keep existing data.

>
>
> Here's another example where I can see being able to manually remove
> old OSM data, and replacing it with GeoBase data. Most of the primary
> highway grid that exists in Alberta was traced from Landsat data, if
> I'm not mistaken. Whatever the source, the existing road data is of
> very poor accuracy.  Steve's road matcher is going to have a horrid
> time trying to match the GeoBase roads against the existing OSM roads
> which can be upwards of 1/2 a mile out of place. I doubt that I would
> find anyone that object to removing the crude existing OSM data in
> favour of the GeoBase data.
>
> An easy solution would be to delete all the crude highway data, and
> then run Steve's script against a blank slate. However, this means
> that someone will have to go through the OSM map before running the
> script to remove the crude data.
>
> I have tracked a number of major highways across Alberta, into BC, and
> also Saskatchewan and used that to replace the crude older highway
> data. Steve's roadmatcher script will probably have an easier time
> matching to those ways, but that still leaves thousands of miles of
> highway that will need to be manually stitched to the GeoBase data.
> Again, I think it would be much faster to modify the GeoBase data to
> match the GPX tracks if need be, rather than manually match the OSM
> ways against the GeoBase data.
>
> Anyone else have any observations or opinions?
>
> James
> VE6SRV
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Question about NIDs

[James Ewen]

On Tue, Jan 20, 2009 at 6:01 PM,   wrote:

> It is not a simple issue. I see 2 options: the first one is to align the osm
> geometry with the nrn-geobase geometry (or the opposite), then add the NIDs.
> At this stage, I wonder if we should take Geobase geometry and join the osm
> attributes. The second option is to use NIDs only for the nrn-geobase
> imported in osm.

I'm kind of stuck, and I'm not sure where to go from here.

I have invested quite a bit of time and effort collecting, importing,
and converting GPS tracks in Fort McMurray. Steve's GeoBase import
script has done a very good job adding GeoBase data all around my data
that I had already put into the OSM database.

Now I need to spend time making the OSM and GeoBase data integrate
together. I can add nodes that correspond to GeoBase nodes, and make
my OSM ways connect to these points. I can attempt to make all of my
ways correspond to GeoBase data, but that is a lot of work, especially
trying to put all the attributes onto each and every one of these
nodes and ways.

What I would like to do, is be able to delete all of my OSM ways, and
replace them with the GeoBase data. From there I would then use the
GPX tracks that I have collected as a basis to modify the GeoBase
data, so that it represents the real world data more accurately.

It just seems to me that my time and efforts would be better invested
by making minor modifications to the GeoBase data to align with my
observations rather than attempting to make major modifications to my
OSM data to align with the GeoBase data.

Don't get me wrong, the GeoBase imported data in the Fort McMurray
area is a good thing in my opinion. I also agree that the GeoBase
update should not automatically overwrite user entered OSM data. What
I am looking for is a way to be able to manually replace my existing
OSM data with GeoBase data, but only at a specific user request, be it
mine or someone else working in an area of their concern.

Here's another example where I can see being able to manually remove
old OSM data, and replacing it with GeoBase data. Most of the primary
highway grid that exists in Alberta was traced from Landsat data, if
I'm not mistaken. Whatever the source, the existing road data is of
very poor accuracy.  Steve's road matcher is going to have a horrid
time trying to match the GeoBase roads against the existing OSM roads
which can be upwards of 1/2 a mile out of place. I doubt that I would
find anyone that object to removing the crude existing OSM data in
favour of the GeoBase data.

An easy solution would be to delete all the crude highway data, and
then run Steve's script against a blank slate. However, this means
that someone will have to go through the OSM map before running the
script to remove the crude data.

I have tracked a number of major highways across Alberta, into BC, and
also Saskatchewan and used that to replace the crude older highway
data. Steve's roadmatcher script will probably have an easier time
matching to those ways, but that still leaves thousands of miles of
highway that will need to be manually stitched to the GeoBase data.
Again, I think it would be much faster to modify the GeoBase data to
match the GPX tracks if need be, rather than manually match the OSM
ways against the GeoBase data.

Anyone else have any observations or opinions?

James
VE6SRV

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

Re: [Talk-ca] Question about NIDs

[michcasa]

On Jan 20, 2009 12:48am, James Ewen  wrote:
On Mon, Jan 19, 2009 at 6:53 PM, Richard Degelder rtdegel...@gmail.com>  

wrote:




> Is there a process to include the NID, in an

> appropriate manner, with the import data that was derived from GeoBase?



In Steve's upload, we have a UUID with each element. I believe that is  

the NID.




geobase:uuid f722391f5b5d4eb1877a24fd69365ff8



> And has there been any considerations as to how to add the NID

> attributes to those ways already within OSM?



That, I'm not sure how to handle, especially when the OSM nodes and

ways won't match up with the GeoBase nodes and ways. How would you

match them when there may be 3 OSM nodes and only 2 GeoBase nodes, or

more likely 6 GeoBase ways making up a roadway that is defined by only

one OSM way.


It is not a simple issue. I see 2 options: the first one is to align the  
osm geometry with the nrn-geobase geometry (or the opposite), then add the  
NIDs. At this stage, I wonder if we should take Geobase geometry and join  
the osm attributes. The second option is to use NIDs only for the  
nrn-geobase imported in osm.


Michel




James

VE6SRV



___

Talk-ca mailing list

Talk-ca@openstreetmap.org

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

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

Re: [Talk-ca] Question about NIDs

[James Ewen]

On Mon, Jan 19, 2009 at 6:53 PM, Richard Degelder  wrote:

> Is there a process to include the NID, in an
> appropriate manner, with the import data that was derived from GeoBase?

In Steve's upload, we have a UUID with each element. I believe that is the NID.

geobase:uuid f722391f5b5d4eb1877a24fd69365ff8

> And has there been any considerations as to how to add the NID
> attributes to those ways already within OSM?

That, I'm not sure how to handle, especially when the OSM nodes and
ways won't match up with the GeoBase nodes and ways. How would you
match them when there may be 3 OSM nodes and only 2 GeoBase nodes, or
more likely 6 GeoBase ways making up a roadway that is defined by only
one OSM way.


James
VE6SRV

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

[Talk-ca] Question about NIDs

[Richard Degelder]

So far Steve has demonstrated, with the Fort McMurray import that we can
detect the data that is currently available and only add the new
roadways to OSM.  Michel is, using different tools, going to do the
same.  So we are going to have two methods of augmenting the current
data within OSM to incorporate GeoBase.

This is all good, we are going to need to do this to improve the map for
Canada.  And we are doing it without damaging the current contents of
OSM that was put there by the different users, one of the goals when we
started the import.  There may be some issues but from the work I have
been doing to check the data I have found very little that would make me
uncomfortable in the least.  I approve of the way Steve is doing the
imports.

But my question is about another goal of the import process.  The value
of the GeoBase data lies in both augmenting the current contents of OSM,
which we are doing with the import of roadways that are not currently
within OSM, and the ability to update OSM with either new data available
from GeoBase or from the GeoBase updates to their current data.  For
this to work we need to incorporate the GeoBase NID for every one of
their segments.  Is there a process to include the NID, in an
appropriate manner, with the import data that was derived from GeoBase?
And has there been any considerations as to how to add the NID
attributes to those ways already within OSM?

Without the inclusion of the NID, either on the currently existing OSM
data or on the data we are currently importing from GeoBase, our ability
to update the information based on those NIDs is going to be severely
curtailed.  Without NIDs the GeoBase import becomes a one time event and
will not benefit from updates nor from additional information that will
become available from GeoBase in the future.

On the other hand having the NID available for all appropriate ways
means that when we want to import the roadways for any province that
does not have the complete data set, such as road names and address
ranges, or to incorporate any new data, such as Postal Codes, we can do
so with full confidence that when that data becomes available it will be
a simple step to run a script that adds the additional attributes based
on those NIDs.  But we are going to have to have a clear process on
adding the NID as an attribute to all existing ways as well as for those
we are adding now though the GeoBase import.

It is acceptable to worry about having the NID available later while we
are working on importing the roadways from GeoBase to make the road
network complete.  But there should also be some thought as to how we
are going to go about adding those attributes later.  To add a lot of
new data, that has the current GeoBase NID readily available, without
any idea of how we are eventually going to be able to add it in late
means that we are only compounding the problem later when there is
significantly more data, due to the import, than we are currently
facing.  The current contents of OSM does not have the GeoBase NID and
so it will have to be added at some point.  Compounding the problem with
even more ways within OSM, ways that within GeoBase had an NID, only
makes the issue more difficult.

Richard Degelder


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

Re: [Talk-ca] Question about using Relationships

[Corey Burger]

On Sat, Dec 20, 2008 at 10:08 AM, Richard Degelder  wrote:
> I have seen the wiki for relationships
> http://wiki.openstreetmap.org/wiki/Relations but have some questions about
> it.  I am hoping that someone can clarify them for me.
>
> If I want to have something like a bus route as a relation on a way but the
> bus route does not follow the entire length of that way, there is a portion
> of the way before and after the portion used by the bus, how would I go
> about adding that relation?  Is it required that I divide the way into the
> segments into before the bus enters the way, the portion used for the bus
> route, and the portion after the bus has left the way or is there another
> means, without dividing the way into segments, that I can have the
> relationship  for only the pertinent portion of the way on which the bus is
> traveling.  Having to divide a way, especially for a small portion on which
> a bus route runs or where there is a lot of routes converging/diverging over
> a short portion of a way seems to be inefficient and potentially messy for
> the map.

You need to divide the way up into multiple pieces, yes. (btw, avoid
the word segments, as that is a term for a discontinued data type, so
people might get confused). As for it being messy, it isn't because
both mapnik and osmarender join ways back together before they render
them.

Cheers,

Corey

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

[Talk-ca] Question about using Relationships

[Richard Degelder]

I have seen the wiki for relationships
http://wiki.openstreetmap.org/wiki/Relations but have some questions about
it.  I am hoping that someone can clarify them for me.

If I want to have something like a bus route as a relation on a way but the
bus route does not follow the entire length of that way, there is a portion
of the way before and after the portion used by the bus, how would I go
about adding that relation?  Is it required that I divide the way into the
segments into before the bus enters the way, the portion used for the bus
route, and the portion after the bus has left the way or is there another
means, without dividing the way into segments, that I can have the
relationship  for only the pertinent portion of the way on which the bus is
traveling.  Having to divide a way, especially for a small portion on which
a bus route runs or where there is a lot of routes converging/diverging over
a short portion of a way seems to be inefficient and potentially messy for
the map.

Any suggestions would be appreciated.

Thanks.

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