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, 

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 <pbouc...@lavoile.com>
 À : 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

[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 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 s.adam.mar...@gmail.com
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

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 s.adam.mar...@gmail.com
 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 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 andrew.alli...@teksavvy.com 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 s.adam.mar...@gmail.com
  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

[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 kli...@gmail.com 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 andrew.alli...@teksavvy.com 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 s.adam.mar...@gmail.com
  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

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

[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

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

[Corey Burger]

On Sat, Dec 20, 2008 at 10:08 AM, Richard Degelder rtdegel...@gmail.com 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