Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

Hi Jochen,

Maybe a MapRoulette challenge might even not be necessary. Yesterday I 
started to clean up a bit in Québec, but since it was already past 
midnight for me, I wanted to continue this morning. To my surprise 
Pierre has done a lot of work and now the entire province of Québec 
looks to be free from these errors. I just could find three errors, and 
fixed them. Bon travail, Pierre!


The OSM inspector will still be a good idea, in order to spot future errors.

To all, this is the procedure I used yesterday, and probably something 
similar also by Pierre.

* Not sure if it is a requirement, but it's better to use 64 bit Java.
* You'll need JOSM with the remote control plugin. You'll also need to 
start JOSM.
* Use Pierre's Overpass query (http://overpass-turbo.eu/s/q5K), and 
zoom/pan to the area of interest.
* Press Run and let Overpass do its work. Don't be afraid when Overpass 
mentions that the result is huge if you have a modern computer. Last 
night I wasn't experiencing any problems with 30MB data.
* Press Export, and choose JOSM. Press "Repair query" when Overpass asks 
you to decide.
* JOSM starts downloading the data. Note that you're only getting the 
outer rings.
* Go to these rings one by one, and load data (at least you'll need the 
relationship itself).

* Remove the natural=wood tag from the outer ring.
* Eventually JOSM starts looking cluttered, because of all the extra 
data. You can use the search query "type:way natural=wood role:outer" to 
see if there are still rings needing work.
* Upload your changes. Be prepared to handle conflicts if someone else 
is working near you on this issue as well.

* After a while, check Overpass Turbo again.

I'm not sure what the update frequency is, but Pierre's changes from 4 
hours ago were already processed.


Good luck!

Frank


On 01-07-2017 09:52, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:

On 30-06-2017 21:21, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
case of old style multipolygon, in Manitoba. Last week, when you posted your
original message, I just saw one case in New Brunswick. IIRC, it was a park,
not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.

Ah, ok, now I understand. Since there was a lot of discussion about old
style multipolygon tagging, and since this type of problem hasn't been added
to OSM inspector,  this wasn't immediately obvious.

In the OSM inspector other errors can be seen, but the most prevalent one is
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
which seems urgent to me.

Here is an example of a forest multipolygon, imported by me
(canvec_fsteggink). It is still version 1, but it has tags on the relation,
not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
cases in the OSM inspector.

So, I'd like to ask you to give a couple of examples where data imported
from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/relation/541821

How difficult would it be to add this to OSM inspector? Not everybody has
Postgres running, and is able to use osm2pgsql. Yes, there is documentation,
but it requires some technical skills. Also, it would be very convenient to
have this updated daily.

It is not that difficult to add to the OSM Inspector and if I have the
time I'll work on that together with the Geofabrik people.


When we have clear examples, then it might be easier to come up with a plan
how to fix it. But so far, I see absolutely no reason why Canada stands out
in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
but as others already have pointed out, mapping everything by hand in
especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases worldwide are in
 Canada and
b) most of these problems are probably caused by one little program, the
 program used to convert/import the CanVec data.

As you might have noticed, later imports, like the example I provided, don't
have that issue anymore. I'm mentioning this to express that not _all_
Canvec data is at fault! Only the first couple of versions. However, for
some reason this was never noticed up until a point that collabo

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

llly oldwas it possible that was a way of tagging
back in the days? Or was it created initially as a polygon and was
later converted to a relation?

Canvec 10.0 doesnt have the issues of double tagging, just overlapping

On Jun 30, 2017 3:22 PM, "Jochen Topf" <joc...@remote.org
<mailto:joc...@remote.org>> wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
> Maybe I'm not understanding it, but in the OSM inspector [1]
I just see one
> case of old style multipolygon, in Manitoba. Last week, when
you posted your
> original message, I just saw one case in New Brunswick.
IIRC, it was a park,
> not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are
on the
outer ways and not on the relation), but multipolygons where
the tags
are on the relation AND on the ways.

> In the OSM inspector other errors can be seen, but the most
prevalent one is
> "Touching rings". Maybe indeed a case of suboptimal mapping,
but nothing
> which seems urgent to me.
>
> Here is an example of a forest multipolygon, imported by me
> (canvec_fsteggink). It is still version 1, but it has tags
on the relation,
> not on the rings (except for the quarries): [2]
> This is from Canvec v7.0. IIRC, we started at v6.0, and the
last version I
> know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not
seeing any such
> cases in the OSM inspector.
>
> So, I'd like to ask you to give a couple of examples where
data imported
> from Canvec is clearly wrong with regard to old style
multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954 226a3acab882d28d8500ddef8203d/
same-tags-ca.pbf

<https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf>

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/r elation/541821
<http://www.openstreetmap.org/relation/541821>

> When we have clear examples, then it might be easier to come
up with a plan
> how to fix it. But so far, I see absolutely no reason why
Canada stands out
> in a negative way. Yes, we all acknowledge that Canvec data
is suboptimal,
> but as others already have pointed out, mapping everything
by hand in
> especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases
worldwide are in
   Canada and
b) most of these problems are probably caused by one little
program, the
   program used to convert/import the CanVec data.

Mapping Canada "by hand" might be difficult because it is such
a huge
country and there aren't that many mappers. But the same
arguments goes
for why you have to be extra careful importing data. If you break
something, there are not enough people to fix it manually.
And, yes,
errors do happen. And if we find them, we fix them and move
on. But
errors from imports can be so huge there aren't enough people
there to
fix them manually. So I think it is the job of those who did
the import
in the first place, to fix their work. If you add data to OSM
you take
on a certain responsibility. If you add more data, you have a
larger
responsibility. But saying: We don't have the manpower, so we
are taking
a shortcut and then, when it turns out the shortcut wasn't so
short
after all, whining that you don't have the manpower to fix it.
That
can't be the excuse.

Jochen
--
Jochen Topf joc...@remote.org <mailto:joc...@remote.org>
https://www.jochentopf.com/ +49-351-31778688

__ _
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.or g/listinfo/talk-ca
<https://lists.openstreetmap.org/listinfo/talk-ca>

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

[Frank Steggink]

On 30-06-2017 21:21, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
case of old style multipolygon, in Manitoba. Last week, when you posted your
original message, I just saw one case in New Brunswick. IIRC, it was a park,
not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.
Ah, ok, now I understand. Since there was a lot of discussion about old 
style multipolygon tagging, and since this type of problem hasn't been 
added to OSM inspector,  this wasn't immediately obvious.

In the OSM inspector other errors can be seen, but the most prevalent one is
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
which seems urgent to me.

Here is an example of a forest multipolygon, imported by me
(canvec_fsteggink). It is still version 1, but it has tags on the relation,
not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
cases in the OSM inspector.

So, I'd like to ask you to give a couple of examples where data imported
from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/relation/541821
How difficult would it be to add this to OSM inspector? Not everybody 
has Postgres running, and is able to use osm2pgsql. Yes, there is 
documentation, but it requires some technical skills. Also, it would be 
very convenient to have this updated daily.

When we have clear examples, then it might be easier to come up with a plan
how to fix it. But so far, I see absolutely no reason why Canada stands out
in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
but as others already have pointed out, mapping everything by hand in
especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases worldwide are in
Canada and
b) most of these problems are probably caused by one little program, the
program used to convert/import the CanVec data.
As you might have noticed, later imports, like the example I provided, 
don't have that issue anymore. I'm mentioning this to express that not 
_all_ Canvec data is at fault! Only the first couple of versions. 
However, for some reason this was never noticed up until a point that 
collaborative action was done to have it fixed. Probably because the 
rendering pipeline of the slippy map was accepting this kind of tagging 
up until recently.

Mapping Canada "by hand" might be difficult because it is such a huge
country and there aren't that many mappers. But the same arguments goes
for why you have to be extra careful importing data. If you break
something, there are not enough people to fix it manually. And, yes,
errors do happen. And if we find them, we fix them and move on. But
errors from imports can be so huge there aren't enough people there to
fix them manually.
The world is so huge that there aren't enough people to create and 
maintain a global world map. However, OSM exists. Fixing errors can also 
be crowdsourced. Martijn van Exel is really doing a great job with 
MapRoulette, for instance. Although fixing errors (cleaning up the mess 
left behind by others) is not nearly as rewarding as mapping, it might 
be easier to do, especially since there is no need for a lot of 
creativity when fixing the same kind of errors.

So I think it is the job of those who did the import
in the first place, to fix their work. If you add data to OSM you take
on a certain responsibility. If you add more data, you have a larger
responsibility.
The person who did most work initially on the Canvec import has already 
left OSM about five years ago. This was during the license change. He 
joined one of the forks, from which we hear nothing nowadays. So, don't 
count on him, and possibly not on others who were working on the Canvec 
import at that time. I'm sure he and others who were involved at that 
time regret certain decisions being made and actions being done.


However, the import was supported by the majority of the community at 
that time, and although there are people who have criticized the import 
(and also of the Geobase roads) they still exist in OSM and are 
gradually being improved by others.

But saying: We don't have the manpower, so we are taking
a shortcut and then, when it turns out the shortcut wasn't so shor

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

Hi Jochen,

Maybe I'm not understanding it, but in the OSM inspector [1] I just see 
one case of old style multipolygon, in Manitoba. Last week, when you 
posted your original message, I just saw one case in New Brunswick. 
IIRC, it was a park, not even from the Canvec import.


In the OSM inspector other errors can be seen, but the most prevalent 
one is "Touching rings". Maybe indeed a case of suboptimal mapping, but 
nothing which seems urgent to me.


Here is an example of a forest multipolygon, imported by me 
(canvec_fsteggink). It is still version 1, but it has tags on the 
relation, not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version 
I know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any 
such cases in the OSM inspector.


So, I'd like to ask you to give a couple of examples where data imported 
from Canvec is clearly wrong with regard to old style multipolygon 
tagging. When we have clear examples, then it might be easier to come up 
with a plan how to fix it. But so far, I see absolutely no reason why 
Canada stands out in a negative way. Yes, we all acknowledge that Canvec 
data is suboptimal, but as others already have pointed out, mapping 
everything by hand in especially remote areas is nearly impossible.


Regards,

Frank

[1] http://tools.geofabrik.de/osmi/?view=areas
[2] https://www.openstreetmap.org/relation/1481163/history

On 30-06-2017 09:52, Jochen Topf wrote:

Hi!

A week ago I wrote this email and nobody answered it yet. Does that
mean that nobody feels responsible for the import that created this data
and nobody here cares for this data?

I see three ways forward:
* We do nothing. The broken data stays in OSM. Not a good solution,
   because every user of the data has to work around this or handle the
   complaints.
* The Canadian community steps up and fixes the data, automatically or
   manually.
* We ask the Data Working Group to remove the broken import.

Jochen

On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:

Date: Thu, 22 Jun 2017 11:38:15 +0200
From: Jochen Topf 
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Multipolygon problems

Hi!

In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
the OSMF tile servers. This new version of the style doesn't take
old-style multipolygons (where the tags are on the outer ways instead of
on the relation) into account any more. In a huge effort in the last
months we have converted all old-style multipolygons to the modern
tagging, so this is a good step!

Unfortunately, as a side-effect of this change, many multipolygon
relations now appear wrong on the map. This is the case for multipolygon
relations that have the same tags on the relation as well as on (some of
the) outer or inner ways. This is *wrong* tagging, and needs to be
fixed. (Note that this always was wrong tagging, even before we
deprecated old-style multipolygons, but the way the software worked with
old-style multipolygons, this problem was not visible on the map. But
now it is.)

Here is an example: http://www.openstreetmap.org/relation/1330741 . As
you can see (unless somebody fixes this :-) the clearing in the forest
that should just have grass, also has tree symbols on it. In many other
cases it is not this obvious, there are just islands in a river missing
or so.

There are about 50,000 cases like this worldwide, forests, waterways,
all sorts of areas. But the worst problem is in Canada. There are about
15,000 affected relations, most from the CanVec imports.

First, we have to make sure that there are no further imports of broken
data. I hope the people who have done those imports (and might still
continue) are here on this mailing list. If not please make them aware
of this issue and/or put me in touch with them. Second, somebody needs
to clean up the broken data, either automatically or manually. 99% of
the data has not been changed since the import, so it might be feasible
to do an automatic cleanup, but somebody has to do this. Otherwise we'll
have to do a manual cleanup, through tools such as Maproulette and the
OSM Inspector. I am currently in the process of creating Maproulette
challenges for other areas of the planet, but will not do this for
Canada at this time. Lets discuss this here first.

I can provide OSM data extracts, statistics, etc. if somebody wants to
look at the data.

All of this is part of a larger effort to fix areas in OSM. See
http://area.jochentopf.com/ for more information. There is also a thread
on the talk mailinglist at
https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html
and this issue
https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
News of the effort are posted regularly to
https://github.com/osmlab/fixing-polygons-in-osm/issues/15 .

Jochen
--
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

Re: [Talk-ca] Highway recoding

[Frank Steggink]

Hi Daniel,

Actually, the part between Quebec City and Beaupré of Route 138 should 
still be tagged as a trunk. Beaupré is not a large population centre, 
but the layout of the road is almost that of a motorway. Except that 
there are traffic lights instead of interchanges.


Regards,

Frank

On 25-7-2015 19:10, Daniel Begin wrote:


I think we are evolving to a consensus that makes sense.

I have received some examples that are quite right in QC context. For 
those who know the area, Route 175 up to Saguenay is obviously a “type 
1” trunk road while Route 138 northeast from Quebec City isn't.


However, I hope everyone concerned will give their “two cents” because 
the context in Manitoba or in Yukon may be (is) quite different, and I 
do not want an Eastern centric solution on the subject :-)


Best regards,

DanielI

*From:*Daniel Begin [mailto:jfd...@hotmail.com]
*Sent:* July-24-15 10:09
*To:* 'Adam Martin'; 'Tristan Anderson'
*Cc:* talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] Highway recoding

“… [TCH] is automatically a trunk route given that it is, at its most 
basic point, the central connection between major settlements …”


Interesting… it is type 2 definition proposed by Tristan but without 
the concept of distance. IMHO, It highlights the fact that, depending 
on how you define central connection, major settlements, or distant 
population centres, you may ends up with the Britain situation – or 
even worst.


Combining two very different objectives (types 1 and 2) in one 
definition leads to confusion. What about a rationale revolving around 
Type 1 definition but considering the TCH as a “special case” as 
suggested by Martin?


-OSM road classes mostly aim toward Type 1 definition, so be it for 
trunks;


-Since TCH could be consider as the only highway connecting most major 
population centres across the country, we could agree to tag it 
whether motorway or trunk depending on the infrastructure. There 
should then be no more confusion with this only one exception.


However, we could also manage all type 2 definitions, such as the ones 
described in document (a) with relation:route (b) but it is a bit more 
complex and less visual when looking at Mapnik.


Other thoughts, comments?

Daniel

a) http://www.comt.ca/english/NHS-report-english.pdf

b) http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes

*From:*Adam Martin [mailto:s.adam.mar...@gmail.com]
*Sent:* July-24-15 07:08
*To:* Tristan Anderson
*Cc:* Daniel Begin; Stewart C. Russell; talk-ca@openstreetmap.org 
mailto:talk-ca@openstreetmap.org

*Subject:* Re: [Talk-ca] Highway recoding

Reviewing the types that you suggest here, the result seems 
reasonable. Major Canadian Highways are generally a blend of the two, 
I find. Type 1 trunks rely on restricted access and the main highways 
in cities are generally limited in this manner. Likewise, these 
restrictions lift, in a sense, outside the city where they switch to 
connecting major settlements together (Type 2).


That said, I think that most would agree that the TransCanada Highway 
is automatically a trunk route given that it is, at it's most basic 
point, the central connection between major settlements, especially 
across provincial borders. I assume that the routes that leave the TCH 
to go to other major settlements would need to be at the same class as 
the TCH, if they are multi-lane highways used to connect settlements. 
Or are we to designate them down a classification and leave Trunk for 
the TCH alone?


On Thu, Jul 23, 2015 at 6:48 PM, Tristan Anderson 
andersontris...@hotmail.com mailto:andersontris...@hotmail.com wrote:


So it seems like we're coming to some agreement.  The current Canadian 
definition based on that 2005 document should be replaced with 
something else that is consistent with the rest of the world.  Once we 
find this new definition, the appropriate wiki pages should be updated.


I took a look around the world and finally saw some consistency in how 
trunk tags are used.  Stewart's guidelines are basically correct, but 
I think I can hammer out a more specific description.  There are two 
types of roads with are both usually tagged highway=trunk:



(1) Limited access highways.  This is a physical description for a 
road that has some of the characteristics of a motorway.  They are 
often dual carriageways of fairly high speed.


(2) Highways connecting distant population centres.  This is a 
functional description for a road where used by cars and heavy trucks 
travelling long distances or between major cities.  Although usually 
two lanes, in more remote areas these roads may have very light 
traffic, be unpaved, or be slow.


In some parts of the world, like Germany, France and the eastern 
United States, all trunk roads are type (1) because long-distance 
travel is generally done on their dense networks of motorways.


Conversely, in large swathes of Australia and Canada, as well as in 
much of the developing world, all trunk roads 

Re: [Talk-ca] Discussion: zones boisées

[Frank Steggink]

Hi Dega,

Sorry, you can't just get away with not creating holes for lakes, 
clearings, etc. What if you get an extract of OSM, and you're only 
interested in the forests, because you want to calculate the percentage 
of forest coverage. You don't get information about lakes, heath and 
other land uses when you don't cut out holes from multipolygons.


A better idea might be cutting the forest polygons along the roads. That 
way they become much more manageable, so forests crossing tile 
boundaries can be merged as well.


For the north this might not work well, because of a lack of roads. Also 
rivers could be used as forest delimiters, but although there are a lot 
of rivers, very large chunks of forests will likely remain.


However, there remains another problem, which is also shown near Lac 
Laporte, namely inconsistent landuse along sheet boundaries. That can't 
be easily fixed, especially not when there is no detailed imagery.


The problem of the lakes which are not merged should be fixed. I know, 
I've imported quite a lot of Canvec data myself, and I haven't always 
followed the best practices myself, but it's pretty an arduous task. 
However, it is doable. Recently I've imported a few sheets, and I took 
attention of merging lakes and avoiding duplicate rings. (As a 
GIS-professional, I still don't see a problem with the latter, but it's 
OSM practice to get rid of them.)


Regards,

Frank

On 19-11-2014 17:06, Ga Delap wrote:

Plusieurs (et j'en suis) ont exprimé leur désir d'avoir une meilleure
couverture de forêt sur la carte OSM. Ces zones de forêt sont venues avec les
importations CanVec mais ne progressent plus depuis un certain temps. Le
présent article propose une façon de réaliser la forêt sans utiliser les abus
de la méthode CanVec.

Voyons un exemple. Dirigez votre éditeur préféré vers -74.375/46.1875 ou
visionnez:
 http://www.openstreetmap.org/#map=16/46.1875/-74.3750
Vous y verrez deux tuiles de forêt. Chacune a été crée avec un rectangle de
type natural:wood. Un simple rectangle de 4 points qu'on peut créer
facilement. Cette tuile peut être vue simplement avec:
 http://openstreetmap.org/way/307466266


Voyons un autre exemple un peu plus à l'ouest (-74.500/46.1875). Dans votre
éditeur, sélectionner la ligne qui délimite la tuile sud-ouest. On peut
constater qu'elle est beaucoup plus complexe. On peut voir l'ensemble de cette
ligne avec:
 http://openstreetmap.org/way/307466267
Elle est composée d'environ 1600 points. Elle est complexe parce qu'elle
utilise l'approche everything but the kitchen sink. La tuile définit non
seulement la forêt mais aussi les lacs, les rivières et les clairières. Pire
encore, ce chemin de 1600 points fait partie d'une relation qui contient
plusieurs dizaines de tels chemins.
Affichez http://www.openstreetmap.org/relation/2368823 et remarquez le temps de
chargement de la page.

Revenons au premier exemple:
 http://www.openstreetmap.org/#map=14/46.1875/-74.3750
La forêt est un simple rectangle mais les lacs, les rivières et les chemins se
superposent à la forêt. Il n'est donc pas nécessaire que le contour de forêt
suive le contour des lacs et des rivières. Il y a un gain énorme en
simplicité.

Voyons un autre problème des tuiles CanVec:
 http://www.openstreetmap.org/#map=17/46.25047/-73.24885
Pour comprendre pourquoi il y a 3 Lac Laporte il faut utiliser l'éditeur:
 http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.24885
Les tuiles CanVec ont divisé le lac en 3 parties et ont créé 3 entités
natual:water, chacune avec le nom Lac Laporte. Pas fort!
Sur la même image, remarquez que le chemin Montée Ouest est fait de 2
segments de couleur différente. C'est parce que ce chemin a été défini de 2
façons différentes et, par conséquent, on ne peut pas fusionner les 2 segments
ensemble. L'un des segments vient de CanVec6 et l'autre de CanVec7. Belle
rigueur!
C'est un non-sens qu'une entité soit séparée en plusieurs parties parce
qu'elle est à cheval sur une tuile.

Le but de mon intervention est d'affirmer qu'il ne faut plus importer de tuile
CanVec dans sa forme actuelle. Elles rend la carte lourde et difficile à éditer
par des humains.
Peut-on remplacer les tuiles de forêt par de simples rectangles? Oui et non.
Les tuiles CanVec sont des multi-polygones et celà permet des trous. Ces trous
sont utilisés (entre autres) pour représenter des clairières. Donc, au lieu
d'un rectangle, on pourrait utiliser un multi-polygone avec des trous. Mais
est-ce bien  la bonne façon?
Un trou (tel qu'uitlisé par CanVec) définit une zone undefined qui apparaît en
blanc sur la carte. Ne serait-il pas mieux de créer une entité heath (ou
autre) pour représenter cette clairière? Une clairière n'est pas un trou dans
une forêt, tout comme une île n'est pas un trou dans un lac.

J'aimerais qu'il y ait une discussion sur les points suivants:
1) est-ce que les tuiles CanVec sont la meilleure façon de représenter la
forêt?
2) si 

Re: [Talk-ca] coastline between Montreal and Sorel, Quebec

[steggink]

Another option is to tag water as coastline at places where there is  
significant tide. This will include the estuary up until approximately  
Quebec City.


Regarding tagging the Great Lakes as coastline: why would there be an  
exception for them, where as other large lakes (Great Slave Lake,  
Victoria Lake in Africa, Lake Baikal in Russia, etc.) are not? IMO  
this can be considered as tagging for the renderer.


A better approach would be to prepare a lowres, generalized dataset  
for rendering at low zoomlevels, which only include coastlines and a  
couple of large bodies of large water, depending on size. This file  
could be updated once a year or so. It is not as if the coastline is  
changing so dramatically that it needs to be updated every few weeks.  
I think the quality of the current coast lines in OSM is high enough  
that this decision could be made, especially with the work Christoph  
Hormann has done on Antarctica last year.


Apart from the Great Lakes, this would also mean that the IJsselmeer  
in the Netherlands and two lakes in Russia (Ladoga and Onega) need to  
be retagged. It might be inconvenient, but why isn't that a problem  
for other large lakes?


Regards,

Frank


Quoting perso...@charleskiyanda.com:


The basic technical restrictions are detailed here

http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline

It may well be that the person who fixed the coastline (let's call  
him Pierre, he's on the list) didn't respect those  
conventions/missed a detail/etc and so the change was reverted  
pronto to not screw up with the map rendering. Pierre has contacted  
the person who reverted him, so we'll know more in a bit.


The question of where does the coastline end and riverbank start is  
a question that was probably debated at length 4-5 years ago with no  
clear resolution. The page does mention the great lakes as an  
example of lakes wrongly tagged with coastline, but that will  
probably stay like that in the near future. Personally, I think the  
great lakes should stay as coastline not just because it'd be hard  
to change. It might be worth coming to a consensus here first before  
we try to fix the coastline between Montréal and Sorel. Clearly, the  
current situation is suboptimal.


My personal approach is to try to consider different definitions,  
starting from the one that gives me the eastern most boundary and  
then move westward. The options I can identify are:


--all land that is closer to other land than to international waters  
is coastline (that gives a boundary somewhere around Nova Scotia and  
half-way up Newfoundland)
--Name change boundary: all land that touches water where the  
St-lawrence is still called the St-Lawrence is *not* coastline.  
(That gives a boundary around the Gaspésie peninsula.)
--Salt to fresh water change. That occurs where the Saguenay river  
dumps into the St-lawrence. Anything east would be coastline, west  
would not.
--Historical navigation: Quebec city (or around Rivière-du-Loup and  
Rimouski?) is roughly where boats would get stuck over winter before  
we had really good ice breakers.
--West-side name change: coastline extends through the St-lawrence  
river up until it's no longer called the St-Lawrence river.


I could see a point for going even further up the St-Lawrence and  
including the great lakes, just because of their size, though  
technically they're lakes.


This is probably a case where science, common language, semantics,  
and database theory have trouble.


Charles

Quoting Harald Kliems kli...@gmail.com:


Just to add to that: The question of coastline versus riverbank is not just
a mapping/geographical question, but also a technical one. Because of the
length and complexity of the coastline and the requirement to render it at
low zoom levels, there is special pre-processing for converting the
coastline data into shapefiles that only happens every couple weeks (at
least that used to be case). You can see the effects of this when between
z4 and z5 the parts of the St. Lawrence that are not tagged with coastline
disappears on the standard map.

Now this doesn't necessarily explain why the coastline ends and restarts,
but it might have something to do with it. I would also suggest contacting
the person who did the revert directly.

Harald.


On Thu, Apr 3, 2014 at 10:40 AM, Adam Martin s.adam.mar...@gmail.comwrote:


Charles,

I took a look at the area that you describe and I see what you mean - the
coastline designation disappears around Sorel and reappears just past
Montreal. Looking in the area of the gap, the use of Coastline appears to
suddenly switch to Water and Riverbank. The source of the information
also switches, from the NRCAN database to Bing.

I am not aware of a discussion that flagged this area to be left as-is
on the map. I am also not sure why someone would be protecting the area
from corrections / changes.

However, I believe I can see where the confusion came from (at least

Re: [Talk-ca] GNS tag cleanup

[steggink]

Hi Paul,

gns:jog refers to the sheet number of the Joint Operations Graphics  
map series.
gns:mgrs refers to the Military Grid Reference System, which is  
nothing more than an alternate representation of the coordinate system


IMO both these values can be safely removed.

I don't know about the other ones. Perhaps you can find more  
information here: http://earth-info.nga.mil/gns/html/


Regards,

Frank

Quoting Paul Norman penor...@mac.com:


About 6 years ago, a set of data was imported from GNS, consisting of place
names, mainly of place=town.

As an example, see http://www.openstreetmap.org/node/52556192/history

Thy have a few tags, many of which can probably be safely automatically
eliminated by editor software.

Using the example node, I think the following should be added to the
automatic removal list in editors


gns:dms_lat=490200
gns:dms_long=-1224900
gns:lat=49.03
gns:long=-122.816667
gns:n:xx:full_name=White Rock
gns:n:xx:full_name_nd=White Rock
gns:n:xx:modify_date=1993-12-14
gns:n:xx:sort_name=WHITEROCK
gns:cc1=CA

I'm not sure on the following. Anyone know their history, and if they're of
any use to OSM?

gns:adm1=02
gns:dsg=PPL
gns:fc=P
gns:jog=NM10-08
gns:mgrs=10UEV1340031177
gns:n:xx:nt=N
gns:rc=1
gns:ufi=-575923
gns:uni=-812858


Any comments?


___
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] GNS tag cleanup

[steggink]

Hi Pierre,

Did you intend to post this link:  
http://earth-info.nga.mil/gns/html/gis_countryfiles.html ?


Frank

Quoting Pierre Béland pierz...@yahoo.fr:

This page gives the variables description. To reconcile with GNS, I  
suggest that only UFI and UNI unique identifiers have to be kept.



 
Pierre




 De : stegg...@steggink.org stegg...@steggink.org
À : talk-ca@openstreetmap.org
Envoyé le : Vendredi 14 février 2014 4h39
Objet : Re: [Talk-ca] GNS tag cleanup


Hi Paul,

gns:jog refers to the sheet number of the Joint Operations Graphics 
map series.
gns:mgrs refers to the Military Grid Reference System, which is 
nothing more than an alternate representation of the coordinate system

IMO both these values can be safely removed.

I don't know about the other ones. Perhaps you can find more 
information here: http://earth-info.nga.mil/gns/html/

Regards,

Frank

Quoting Paul Norman penor...@mac.com:


About 6 years ago, a set of data was imported from GNS, consisting of place
names, mainly of place=town.

As an example, see http://www.openstreetmap.org/node/52556192/history

Thy have a few tags, many of which can probably be safely automatically
eliminated by editor software.

Using the example node, I think the following should be added to the
automatic removal list in editors


gns:dms_lat=490200
gns:dms_long=-1224900
gns:lat=49.03
gns:long=-122.816667
gns:n:xx:full_name=White Rock
gns:n:xx:full_name_nd=White Rock
gns:n:xx:modify_date=1993-12-14
gns:n:xx:sort_name=WHITEROCK
gns:cc1=CA

I'm not sure on the following. Anyone know their history, and if they're of
any use to OSM?

gns:adm1=02
gns:dsg=PPL
gns:fc=P
gns:jog=NM10-08
gns:mgrs=10UEV1340031177
gns:n:xx:nt=N
gns:rc=1
gns:ufi=-575923
gns:uni=-812858


Any comments?


___
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] licence et notion de paternité

[Frank Steggink]

Hopefully they'll change the license so it becomes truly open. They 
probably don't have as much experience with open data licenses as we, as 
the OSM community, have. Because we go farther than just visualizing the 
data, these questions were probably beyond their original thoughts about 
how their data would be used.


Frank

On 18-12-2012 14:11, Bruno Remy wrote:


Bonjour Pierre,

Merci pour le suivi. De mon côté j'ai eu quelques échanges avec un des 
principaux membres de Capitale Ouverte, l'équivalent de Québec Ouvert 
à l'échelle de la Ville de Québec.
À première vue, ils sont bien surpris de nos interrogations sur les 
licences et ne voient pas où il y a des blocages ...
Je leur ai soumis un document expliquant les discutions que nous avons 
eu sur la liste-CA et le constat qu'aucune ville au monde n'avait 
exigé qu'on la mentionne sur la MAP, depuis les 8 années d'existance 
d'OSM... Alors pourquoi une exception pour Montréal ou pour la Ville 
de Québec?


Bruno Remy

Le 2012-12-17 20:58, Pierre Béland infosbelas-...@yahoo.fr 
mailto:infosbelas-...@yahoo.fr a écrit :


Bruno,

tiens justement je viens juste d'envoyer un courriel relatif à
Québec Ouvert.

Certaines licences dites libres imposent des restrictions qui ne
sont pas toujours réalisables au niveau de la mention. Mais
normalement une simple mention dans une page ou dans la base de
données suffit.

Quand on regarde les licences des municipalités, on voit toutes
sortes de restrictions au niveau de la mention.
Dans la citation ci-dessous, je ne sais pas comment on peut
l'interpréter. Par exemple, faudrait-il mettre un lien url pour
chaque donnée dans la base? Serait-ce suffisant de fournir cette
info au niveau du changeset?

Pierre


*De :* Bruno Remy bremy.qc...@gmail.com
mailto:bremy.qc...@gmail.com
*À :* talk-ca@openstreetmap.org
mailto:talk-ca@openstreetmap.org talk-ca@openstreetmap.org
mailto:talk-ca@openstreetmap.org
*Envoyé le :* Lundi 17 décembre 2012 20h33
*Objet :* [Talk-ca] licence et notion de paternité

Bonjour,
Une licence qui impose de mentionner la paternité («source»)
des données, ça implique quoi concrètement?
a)Juste un tag source underground dans la BD comme OSM le
fait déjà pour les données de Canvec, Tiger, etc
ou
b)vraiment une mention visible pour les utilisateurs de
l'intreface web, à côté de la mention (c) OpenStreetMap et ses
contributeurs?
Si la réponse est a) on peut l'utiliser. si b) on ne peut
pas incorporer les données.
Voir ci-dessous:

Sous réserve de : Mentionner la paternité de « l’Information »
: sa source (a minima le nom du « Producteur et la date de sa
dernière mise à jour. Le « Réutilisateur » peut notamment
s’acquitter de cette condition en indiquant un ou des liens
hypertextes (URL) renvoyant vers « l’Information » et assurant
une mention effective de sa paternité. Cette mention de
paternité ne doit ni conférer un caractère officiel à la
réutilisation de « l’Information », ni suggérer une quelconque
reconnaissance ou caution par le « Producteur », ou par toute
autre entité publique, du « Réutilisateur » ou de sa
réutilisation.
---
Bruno Remy

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




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



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

Re: [Talk-ca] Internal CanVec conflicts

[Frank Steggink]

On 14-11-2012 19:37, Pierre Béland wrote:


Pierre Lamoureux***:* Mardi 13 novembre 2012 23h54
**
Je suis un nouveau participant au projet OSM, par contre je ne suis 
pas un débutant en cartographie et je saisis assez bien les termes de 
la discussion en cours


En passant, j’ai un peu d’expérience dans l’utilisation de FME pour 
convertir les données CANVEC pour construire des cartes électroniques 
et je peux contribuer dans cette zone.



Pierre,

Bienvenue sur cette liste de discussion.

Je ne connais pas le FME. Sur un groupe de discussion, on je vois Use 
of FME with CGI for online map-delivery.


Est-ce un serveur de cartes? Est-ce OpenSource?

Pierre


Hi Pierre,

FME is an ETL-tool, which stands for Extract, Transform and Load. It is 
proprietary software, made by the Vancouver-based company Safe Software. 
[1] It supports a couple of hundred geospatial formats, both reading and 
writing. Also the OSM format is supported.


There is also an open source geospatial ETL tool, named GeoKettle, an 
extension of Kettle (a metadata driven ETL tool). [2] It is being 
developed by Québec based company Spatialytics. They don't support OSM 
as an output format, but as it is open source it could be extended with 
anyone with the right skills and time.


Frank

[1] http://www.safe.com/fme/fme-technology/
[2] http://www.spatialytics.org/projects/geokettle/


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

Re: [Talk-ca] Internal CanVec conflicts

[Frank Steggink]

Hi Paul,

It probably won't come to you as a surprise if I would say it is 
acceptable, but to a certain degree. A map with no data is not a map. A 
map with inconsistent data is still a map, but obviously something is 
not right. A map with perfectly consistent data doesn't need to tell the 
truth either. Remember the fantasy city someone added about a month ago? 
Furthermore, a map can become outdated. This is also true for OSM.


Anyways, the reason I've been importing Canvec data is to provide more 
coverage, so others can work with it. OSM is a community project, and I 
think everyone has a share in it. This is one of the main reasons I 
started with OSM, because I believe in the ideals and goals. To you it 
might sound that importers like me are leaving a big mess behind for 
others to deal with. To me, it was a choice. The alternative would be 
either no data, or very sparse and incomplete data. It would take ages 
to complete the map, since there are not nearly as much mappers in 
Canada as there are in Germany. A map which is only half complete 
doesn't have half the value of a complete map, but way less. That's also 
the reason I imported forests in suburban areas. It can still be cleaned 
up later. Leaving the forest out of it leaves an ugly gap, and fixing it 
during the import is so time consuming the import would go on endlessly 
(which it does already...).


Also, many or most people who are mapping with OSM do not have a mapping 
or geospatial background. Let me be clear, I think it is wonderful that 
they join OSM and step upon the learning curve to become a contributor. 
On the other hand, in many cases the quality of their contributions are 
not that great. I also don't like the fact that something is abandoned 
half-way (like the Canvec import). So the choice I made was to provide 
them and the rest of the community with some kind of baseline. With the 
Canvec data imported, it makes it easier for people to add POI's and 
other stuff. And while importing, I also fixed other errors which 
existed in the maps. Of course not all of them, but what would be 
reasonably possible from my armchair. Furthermore, the imports I've done 
about half a year ago were aimed at filling gaps between existing 
imports. It is a pretty daunting task, so it is no surprise many have 
stopped, and I just wanted to get the job done.


However, time is limited, so I eventually decided to stop. The reasons 
which motivated me doing imports are no longer enough to continue. It is 
partially due to the criticism of you and others. If my contributions 
are not accepted / acceptable, there is no reason to continue, so I can 
better stop. I also think that OSM has caused a lot of awareness for 
open data, and governments are opening up much more. For example, also 
in the Netherlands a lot of datasets have become open data, like the 
national road register, buildings, and topography. Of course, with the 
availability of Canvec, this is also true in Canada. So for many 
geospatial professionals there is not much reason to continue OSM, 
except when you're interested in areas for which no other alternative 
exists (cycling routes, historic buildings, etc.).


Frank

On 10-11-2012 12:37, Paul Norman wrote:

CanVec data comes from multiple sources and this can lead to internal
inconsistencies. A common case is a new development where there used to be
trees. The tree data in CanVec might be older and show an area as forested
while there is newer road data indicating that the area has been developed.
An example of this type is
http://www.openstreetmap.org/?lat=45.695lon=-73.905zoom=17 although I have
seen many other cases of it.

Another common case is the trees in water problem frequently found in BC. A
typical example is
http://www.openstreetmap.org/?lat=58.648lon=-123.911zoom=17 where there is
a conflict between the water data and the forest data. You need to view the
data as it doesn't show up on the rendering.

Is it the communities view that it is okay to import CanVec without
reconciling the internal differences between the layers?

My view is that importing data without resolving conflicts of this type
where it conflicts with either existing data or internally is not an
acceptable import and indicates the importer did not sufficiently review
what they were uploading.


___
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] Import Canvec : micro-tâches / Canvec imports micro-tasking

[Frank Steggink]

Hi Pierre,

I'm glad to see you're taking a constructive approach towards the 
discussion initiated by Paul :) I definitely agree something needs to be 
done to make imports more manageable, especially the Canvec import. 
There is also an amount of work left behind as I mentioned in my other 
mail. Of course that needs to have some attention as well.


Apart from the inconsistencies, there is for example also the Geobase 
import. In 2009 the available Geobase data didn't contain road names in 
Québec, and by then it was also not clear when it would contain names. 
So there are many areas which have roads without names. Furthermore, 
there have been subsequent Canvec releases in which data / tagging 
issues have been resolved. An example is the use of natural=land tag 
as mentioned by Brian Gamberg, but in one or two releases the 
amenity=school and amenity=prison tags were swapped around as well.


Having some kind of checklist attached to the micro-tasking, combined 
with periodical reviews (which IMHO think are necessary, for example 
with new Canvec releases) and tools like OSM Inspector will also ensure 
that the data quality remains good in the future. For this system to 
work, also areas with existing data (either user-contributed or 
imported), which seem complete should be reviewed.


I'm not familiar with the Linz solution, but perhaps someone like 
Martijn van Exel or the Mapbox guys could help setting up something 
useful and user-friendly.


Frank

On 13-11-2012 21:01, Pierre Béland wrote:

Voir discussion en français / See English discussion below

Paul Norman,sat. november 2012 6h37
** Subject :  Internal CanVec conflicts
 Is it the communities view that it is okay to import CanVec without
 reconciling the internal differences between the layers?

 My view is that importing data without resolving conflicts of this type
 where it conflicts with either existing data or internally is not an
 acceptable import and indicates the importer did not sufficiently review
 what they were uploading.

---

L'import de données est essentiel, si l'on veut couvrir toute la 
surface du Canada. Cependant, il est complexe d'importer des fichiers 
CanVec dans les zones où les données existent déjà. Autant les 
contributeurs inexpérimentés qu'expérimentés sont susceptibles de 
faire des erreurs. Le processus d'importation est souvent trop 
complexe et trop long à réaliser.


Les micro-tâches sont actuellement basées sur les zones géographiques 
,chaquegrille NTS étant subdivisée en plus petites zones. En 
subdivisant par couche thématique, je pense que cela permettrait de 
réduire la complexité des importations CanVec, de réduire les erreurs 
et d'encourager plus de gens à importer.  Si nécessaire en raison de 
la taille, certaines grilles pourraient aussi être subdivisée en zones 
plus petites.


Tout comme pour les fichiers Planet, les fichiers d'import OSM  
pourraient être subsiviés par couches telles que routes, poi, landuse, 
forest, coastlines, limites administratives, autres ...). De cette 
façon, chaque tâche d'importation serait moins complexe à réaliser, 
plus facile à comparer avec ce qui existe déjà. En outre, la tâche 
serait réalisée plus rapidement.


Lorsque une couche telle que les forêts semble moins approprié pour 
une région donnée, il serait facile pour le contributeur d'ignorer 
cette couche. Aussi, les limites administratives et les côtes 
devraient être réservés à des gens plus expérimentés. Les fichiers 
pourraient être regroupés dans un répertoire distinct et couvrir de 
plus grandes zones.


Je pense que nous avons besoin de plus que le fichier Google doc 
actuel pour assurer le suivi des imports.
L'outil linz2osm de Nouvelle-Zélande me semble trop complexe. 
Cependant, il peut nous donner  des idées sur la façon de développer 
un tel outil.


Voir linz2osm New Zealand project.
http://linz2osm.openstreetmap.org.nz/

voir discussion de Glen Barnes, Import list.
http://web.archiveorange.com/archive/v/2u2n5O1bELI3yg2ULjry
---

Data import is essential to cover all of Canada, But it is complex to 
import Canvec files in areas were data already exist. Both 
unexperienced and experienced people may make errors. Import process 
is often too complex and too long to realize.


Micro-tasking presently consist of dividing a a NTS grid area in 
smaller zones. If this micro-tasking was based on layers, I think that 
this would reduce the complexity of Canvec imports, reduce errors and 
encourage more people to import. But if necessary because of size, 
some NTS grids could be subdivided by smaller zones.


The OSM import files would be divided by layers like it is done for 
planet files. There could be layers such as roads, poi, landuse, 
water, forest, coastlines, administrative boundaries, other...). This 

Re: [Talk-ca] Canvec 10 and landcover issues

[Frank Steggink]

On 19-10-2012 21:46, Harald Kliems wrote:

Hi Pierre,
thanks for the response.

On Fri, Oct 19, 2012 at 3:25 PM, Pierre Béland infosbelas-...@yahoo.fr wrote:

I dont know how you conclude that there is no wetlands around this area in
Laval.  It is not sufficient to see houses around to conclude that there is
no wetland. These are often wooded areas with water all over.  Google
physical also shows a stream starting from this area.

The link below shows a comparison of this area with Google imagery.  Are you
sure that there is no wetland in this area.
http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.91012lat=45.69989zoom=17

This is a misunderstanding. I did not mean that there is _no_ wetland
in the area. But I'm pretty certain that the boundaries of the wetland
are wrong:

http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.90457lat=45.69533zoom=17

Aside from the wetland issue (see below), we can probably agree that
the area is not natural = wood, even if some people might have planted
trees in their yards.


The link below shows an aera in Saint-Jean-sur-Richelieu were houses have
been built for over 30 years. Look how many houses were flooded last year.
Zoom in to see areas that were flooded.
http://pierzen.dev.openstreetmap.org/hot/openlayers/inondation-richelieu-2011.htm?zoom=16lat=45.28568lon=-73.24907layers=B000T

My experience, as a volunteer for SOS-Richelieu, last year, showed me how
that too often the municipalities have accepted that contractors build
houses over wetlands. And this was often the case with Laval.

Okay, this is a different issue, coming down to the definition of what
wetland is. I'm by no means an expert, but in my understanding you
can't have a residential area in wetlands. In order to build houses
you must first use drainage channels etc. to turn wetland into
developed land. The fact that there can be flooding in a given area
doesn't make it into wetland to me. The wiki isn't very explicit about
this (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland) but
the specific subtypes seem to hint at a definition stricter than
yours. Maybe someone can tell us what definition is used for Canvec.

Cheers,
  Harald.

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


Hi Harald,

As Paul just explained, the Canvec data comes from different ages, so 
what this basically tells is that 20 or 30 years ago (or maybe just 10 
years ago) this area was a wooded marsh. Unfortunately, this landcover 
data is the best available. (The lower resolution Landsat data can be 
pretty old too, and its resolution makes it unusable.) It still needs to 
be reconciled with the roads, preferably with the help of Bing imagery. 
I'm not sure if a decent resolution is available in this area. Good 
coverage is pretty spotty in Canada.


Regarding the flooding: areas which used to be wetlands in the past are 
still prone to flooding, unless significant work has been undertaken 
from ever happening again (like drainage, diverting streams, putting 
extra soil on top). Especially when buildings are built within the 
channels which have been eroded by rivers, then you can basically wait 
for a disaster to happen.


Frank


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

Re: [Talk-ca] Import des limites administratives, municipalités du Québec

[Frank Steggink]

Hi Pierre,

If I recall correctly, Daniel once mentioned that the municipality  
boundaries were to become part of Canvec. I don't know when that would  
eventually happen, but he or someone from NRCan might confirm that. Or  
someone who has connections in the Quebec government might attempt to  
persuade them to attach a better license to the boundaries which have  
currently opened up.


As for removing the incorrect data: did you try to contact the users  
already, and how did they respond? I see no problem if the data is  
clearly wrong, and/or when the users cannot provide clear sources.  
Boundaries aren't something you can see on the ground (except for a  
few individual markers). On the other hand, if both conditions are  
satisfied (quality and source), then you can't just delete existing  
boundaries, without discussing it with the contributing users first.  
This would only be the case on the Isle of Montreal, if I understand  
correctly.


As for centralizing the import: in the Netherlands we have centralized  
it as well. This is giving good results, since it is clear where the  
responsibilities are. Generally once a year the boundaries are  
updated, because adjustments being made are becoming in effect usually  
on January 1st.


Regards,

Frank

Quoting Pierre Béland infosbelas-...@yahoo.fr:

Les données de limites administratives sont déterminantes pour  
assurer une recherche par nom de rue et municipalité dans OSM. Dans  
ce contexte, plusieurs contributeurs du Québec ont commençé à  
importer des données de limites administratives pour les  
municipalités, dans les régions de Québec, Îles-de-la-Madeleine,  
Montréal, Rive-sud, Saint-Jean-sur-Richelieu et Labelle.  De façon  
générale, les sources de données ne sont pas indiquées, et il y a  
parfois des chevauchements (exemple entre Laprairie et  
Saint-Jean-sur-Richelieu. 


En faisant une recherche sur les chemins et relation de limites  
administratives déjà saisis, j'ai constaté que plusieurs limites  
étaient incomplètes et donc inopérantes. J'ai ainsi réparé les  
limites de plusieurs municipalités sur l'Île de Montréal. Les villes  
de banlieu et Montréal s'affichent maintenant correctement et il est  
possible de faire une recherche à partir d'un nom de rue. Sur la  
Rive-sud, des limites saisies par des contributeurs pour Brossard et  
Laprairie sont actuellement incomplètes et inopérantes.


Dans l'ensemble on se retrouve avec des données disparates dont ont  
ne connait pas toujours la provenance. Ces données se chevauchent,  
sont de formes différentes, ce qui rendra de plus en plus difficile  
à assembler ce puzzle si on poursuit dans cette direction.


Au cours des deux dernières semaines, j'ai corrigé plusieurs  
relations définissant les limites de municipalités du côté de  
Labelle et à Montréal. Et j'ai pu vérifier avec les outils  
appropriés que ces limites fonctionnaient correctement.


Cependant, je fais un pas en avant et deux pas de côté. Des  
contributeurs inexpérimentés continuent à importer des données et  
font des manipulations qui rendent les limites déjà importées ou  
corrigées inopérantes. Si on poursuit dans cette direction, on aura  
le torticoli de l'autruche.


C'est pourquoi je propose d'arrêter l'import et la modification des  
limites administratives de municipalités, arrondissements, etc. et  
d'en discuter sur cette liste avant de poursuivre le travail.


La solution qui me semble le plus réaliste est d'effacer si  
nécessaire les limites déjà importées et de ré-importer à partir  
d'une source unique.


Il faut d'abord s'entendre sur les données à utiliser. Il est prévu  
d'obtenir éventuellement les données du gouvernement du Québec. Dans  
l'éventualité où on devra attendre encore une longue période pour  
obtenir ces données, il y a la possibilité d'utiliser les données de  
Statistique Canada. Celles-ci me semblent assez précises.


Pour le travail d'import, il me semble souhaitable de centraliser ce  
travail. Je suis expérimenté dans le traitement de telles données.  
Si les collaborateurs du Québec sont d'accord, je pourrais  me  
charger du travail d'import.



Pierre




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

Re: [Talk-ca] Canvec import issues

[Frank Steggink]

To be clear, I haven't done full imports. I haven't imported roads or  
water, in order not to duplicate features. Water was previously  
imported by Yan Morin in 2009 (Geobase NHN data), and roads were  
either drawn by users, or a result of the Geobase NRN import. In case  
of water, I only have added a few streams which were missing.


One of the issues is that certain ways are duplicated, because of  
multipolygon holes. That's why I'm gauging your thoughts about it,  
because I don't see that as an issue myself. Perhaps we could come up  
with a proper way how to deal with it.


Another issue which is bothering myself for a long time is the fact  
that Geobase NRN roads don't have road names in Quebec. Road names are  
present in Canvec now. Replacing them manually is a tedious task. I  
have thought about it for quite some time, but I can't come up with a  
better procedure, offering the same quality. I also have considered  
writing tools for them. Any (semi-)automated tools have an inherent  
risk, particularly because it's hard to guarantee they will still do a  
proper job, given the diversity in OSM data.


Frank


Quoting Béland Pierre bela...@yahoo.fr:


David and Paul, do you think this was the problem with these imports???
 
Pierre





De : David E. Nelson denelso...@yahoo.ca
À : Paul Norman penor...@mac.com; talk-ca@openstreetmap.org  
talk-ca@openstreetmap.org

Envoyé le : Mercredi 22 août 2012 21h59
Objet : Re: [Talk-ca] Canvec import issues


Yeah, don't just do blanket imports.  Just import whatever data  
OSM *does not* have.




- David E. Nelson


From: Paul Norman penor...@mac.com
To: 'Daniel Begin' jfd...@hotmail.com; 'Pierre Béland'  
infosbelas-...@yahoo.fr; talk-ca@openstreetmap.org

Sent: Wednesday, August 22, 2012 6:52:12 PM
Subject: Re: [Talk-ca] Canvec import issues


I see the problem as being the importing of everything as being  
the problem, not the geometric model :)

 
From:Daniel Begin [mailto:jfd...@hotmail.com]
Sent: Tuesday, August 21, 2012 1:49 PM
To: 'Pierre Béland'; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues
 
Bonjour Pierre,
 
The Canvec Geometric Model is explained in the following OSM wiki page ...
http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model
 
The model was adopted after discussions with the community. The  
model was designed to simplify the import of a selection of  
features by the  contributors, instead of imposing import the  
entire contents by them.

 
However, history now shows that the community usually imports the  
entire content.

Compromises always bring pros and cons.!-)
 
Best regards,
Daniel
 



From:Pierre Béland [mailto:infosbelas-...@yahoo.fr]
Sent: August-21-12 16:04
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues
 
 
I didn't do Canvec imports too much. Looking at various lakes in  
wooded areas,  I now realize that Canvec imports are often  
(always?) duplicating lakes. I do'nt know what was the reason to  
create these duplicate ways in the Canvec import file.  Should we  
duplicate the lakes to apply a inner role in the relation? Is this  
a reason for that? Or could we instead simply use the existing  
lake with a inner role in the wooded area polygon relation?

 
Pierre



De :Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org
Envoyé le : Mardi 21 août 2012 13h32
Objet : [Talk-ca] Canvec import issues

Hi,

Today I was contacted by someone inquiring (with a somewhat  
hostile tone) after the Canvec import I've done over the weekend  
northwest of Montréal. He was not really happy with the way how  
the import has handled. The way the Canvec data is currently  
provided, leaves some room for improvement. I'm not sure if all  
his issues have been discussed in the past (since I haven't  
followed all Canvec discussions, especially in the beginning), but  
I could see some merit in some of the point.


Some examples he provided come from the Mt. Tremblant area [1].  
Note that the lakes (and most of the streams) were imported  
previously by someone else, based on NHN data, but the same issue  
plays with the Canvec data itself. (This left me to the task to  
leave the Canvec lakes out of the upload, as well as most streams.)


On the left you see Lac Ouimet. He
mentioned that a large part of the ways are duplicated. The outer  
boundary of the wooded area is a separate polygon from the lake  
itself.  However, Lac Gauthier on the right is a different case.  
This lake has been cut out from the woods, and I left the inner  
boundary intact. JOSM is not complaining about this. Since dealing  
with multipolygons remains a sticky issue, I have not done that. I  
think it would be better to take care of these issues with some  
tool. Although using a tool is considered dangerously (and  
rightfully so!), dealing

Re: [Talk-ca] Canvec import issues

[Frank Steggink]

Hi Pierre,

Regarding the duplicated ways, I'll get to that by replying Daniel's mail.
Regarding the toponyms, the user I'm having contact with is refering to 
Sûreté de Québec, for example this page: 
http://www.sq.gouv.qc.ca/poste-mrc-des-pays-d-en-haut/organisation/carte-detaillee-pays-haut.pdf


I don't know if both data sources can be considered public domain.  As 
far as I know, the guidelines for the federal government don't apply to 
provincial and local governments. See also the discussion about 
importing data from the Ville de Québec.


Frank

On 21-8-2012 20:59, Pierre Béland wrote:

Frank

The NEtiquette is always important in these circumstances. Lets hope 
this mapper will learn how to deal with the community.


I Looked rapidly at the data.I see a multipolygon natural=wood 
Relation : 2362646 that contains 72 members. I see that you imported a 
wooded area way=176778952 that is part of this relation. It also 
overlaps for the 2/3 with a lake way=57988179. I see similar situation 
with way 176778559.  Unless I missed something, my understanding is 
that you should simply remove ways 176778952 and 176778559 and any 
others that duplicate what is already defined  by relation 2362646.


The Quebec toponyms may sometime be more complete then Canvec. But not 
all the lakes have names and it is not easy to find infos for a 
specific area. You can  search for a specific name at 
http://www.toponymie.gouv.qc.ca/.
See 
http://www.toponymie.gouv.qc.ca/ct/ToposWeb/recherche.aspx?s=lac-ouimetx=0y=0 
for lac Ouimet results

Pierre


*De :* Frank Steggink stegg...@steggink.org
*À :* talk-ca@openstreetmap.org
*Envoyé le :* Mardi 21 août 2012 13h32
*Objet :* [Talk-ca] Canvec import issues

Hi,

Today I was contacted by someone inquiring (with a somewhat
hostile tone) after the Canvec import I've done over the weekend
northwest of Montréal. He was not really happy with the way how
the import has handled. The way the Canvec data is currently
provided, leaves some room for improvement. I'm not sure if all
his issues have been discussed in the past (since I haven't
followed all Canvec discussions, especially in the beginning), but
I could see some merit in some of the point.

Some examples he provided come from the Mt. Tremblant area [1].
Note that the lakes (and most of the streams) were imported
previously by someone else, based on NHN data, but the same issue
plays with the Canvec data itself. (This left me to the task to
leave the Canvec lakes out of the upload, as well as most streams.)

On the left you see Lac Ouimet. He mentioned that a large part of
the ways are duplicated. The outer boundary of the wooded area is
a separate polygon from the lake itself.  However, Lac Gauthier on
the right is a different case. This lake has been cut out from
the woods, and I left the inner boundary intact. JOSM is not
complaining about this. Since dealing with multipolygons remains a
sticky issue, I have not done that. I think it would be better to
take care of these issues with some tool. Although using a tool is
considered dangerously (and rightfully so!), dealing with
multipolygons is prone to errors as well.

Another issue is that some lakes do not have names, but contain a
separate node (not part of any of the ways) with natural=water and
name=* tags. I can only assume that this comes from the source
data. In many cases it is hard to determine the extent of the
lake, since it can gradually taper into a river. This was not
mentioned directly by the user, but I thought he was referring to
this.

His issue turned out to be somewhat different. There is a place
node near Lac Gauthier, with the same name. I explained to this
that this must be the name of a hamlet. The non-official tag
place=locality is probably due to this confusion. This name is
also visible on the original topo map [2].

Furthermore he noticed that I have duplicated his address nodes
and ways. This was an omission, so I have corrected this. I scan
the existing data in order not to duplicate existing features. Of
course this is prone to errors as well, especially in a large area
which is void of address nodes and ways, except for two ways
around a lake...

I'm not asking anyone for solutions. I can easily think about
them as well, but that doesn't make the problem go away. Thinking
about the solution is the easiest part, but working it out and
implementing it is much more difficult. It is more than simply
typing in some code and then run it over the data. Instead of
doing that, I have tried to explain him something about the hybrid
data model OSM is using (not purely geographical, but also not
purely topological). And of course there is also the gap between

Re: [Talk-ca] Canvec import issues

[Frank Steggink]

Hi Daniel, Pierre,

It is possible to reuse ways in the OSM datamodel, as you know. It is 
also possible to do this, while having to make extracts later. For 
example, when you only want to select lakes, you should do the following 
in JOSM:

* Select natural=water, replace selection
* Select child selected, add to selection
This way you have all lakes, including multipolygon ones with islands. 
Note that the islands could have tags applied on them as well. You can 
deal with them after you've copied the data to another layer.


Anyways, unfortunately it is not possible to have ways being reused 
easily with JOSM. At least not with standard JOSM or the Validator tool. 
Perhaps there is a plug-in. I haven't looked into that. However, if this 
functionality were to be implemented, it could easily open a new can of 
worms. Sometimes it also happens that functionality is revised (wholly 
or partially). For example, that is the case with unclosed ways. Now 
it isn't possible to merge duplicate nodes with the Validator tool. With 
all the crossing address interpolation ways and streams, I need to merge 
them manually tens of times per sheet, sometimes even up to a hundred 
times. (Probably not much more, because sheets are being split up 
farther in crowded, residential areas.)


History also shows that everyone has his own standards, even amongst all 
the people who have imported Canvec data. However, that is an entirely 
different discussion...


Frank

On 21-8-2012 22:49, Daniel Begin wrote:


Bonjour Pierre,

The Canvec Geometric Model is explained in the following OSM wiki page ...

http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model

The model was adopted after discussions with the community. The model 
was designed to simplify the import of a selection of features by the  
contributors, instead of imposing import the entire contents by them.


However, history now shows that the community usually imports the 
entire content.


Compromises always bring pros and cons.!-)

Best regards,

Daniel



*From:*Pierre Béland [mailto:infosbelas-...@yahoo.fr]
*Sent:* August-21-12 16:04
*To:* talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] Canvec import issues

I didn't do Canvec imports too much. Looking at various lakes in 
wooded areas,  I now realize that Canvec imports are often (always?) 
duplicating lakes. I do'nt know what was the reason to create these 
duplicate ways in the Canvec import file.  Should we duplicate the 
lakes to apply a inner role in the relation? Is this a reason for 
that? Or could we instead simply use the existing lake with a inner 
role in the wooded area polygon relation?


*/Pierre/**//*



*De :*Frank Steggink stegg...@steggink.org
*À :* talk-ca@openstreetmap.org
*Envoyé le :* Mardi 21 août 2012 13h32
*Objet :* [Talk-ca] Canvec import issues


Hi,

Today I was contacted by someone inquiring (with a somewhat hostile 
tone) after the Canvec import I've done over the weekend northwest of 
Montréal. He was not really happy with the way how the import has 
handled. The way the Canvec data is currently provided, leaves some 
room for improvement. I'm not sure if all his issues have been 
discussed in the past (since I haven't followed all Canvec 
discussions, especially in the beginning), but I could see some merit 
in some of the point.


Some examples he provided come from the Mt. Tremblant area [1]. Note 
that the lakes (and most of the streams) were imported previously by 
someone else, based on NHN data, but the same issue plays with the 
Canvec data itself. (This left me to the task to leave the Canvec 
lakes out of the upload, as well as most streams.)


On the left you see Lac Ouimet. He mentioned that a large part of the 
ways are duplicated. The outer boundary of the wooded area is a 
separate polygon from the lake itself.  However, Lac Gauthier on the 
right is a different case. This lake has been cut out from the 
woods, and I left the inner boundary intact. JOSM is not complaining 
about this. Since dealing with multipolygons remains a sticky issue, I 
have not done that. I think it would be better to take care of these 
issues with some tool. Although using a tool is considered 
dangerously (and rightfully so!), dealing with multipolygons is 
prone to errors as well.


Another issue is that some lakes do not have names, but contain a 
separate node (not part of any of the ways) with natural=water and 
name=* tags. I can only assume that this comes from the source data. 
In many cases it is hard to determine the extent of the lake, since it 
can gradually taper into a river. This was not mentioned directly by 
the user, but I thought he was referring to this.


His issue turned out to be somewhat different. There is a place node 
near Lac Gauthier, with the same name. I explained to this that this 
must be the name

Re: [Talk-ca] opendata datasets

[Frank Steggink]

Hi Bruno,

Although there are many more European datasets listed in the catalogue, 
many of them are very small, covering only a city, province, etc. In 
North America there are a few, but very large datasets which have been 
imported or are in the process of being imported. Examples in the US are 
the Tiger dataset (imported in 2007/2008) and the NHD dataset 
(waterways). In Canada there are of course Canvec and previously 
Geobase. So, the amount of imported data in North America is larger than 
in Europe. And of course, in Europe the situation differs by country. 
For instance, in the Netherlands there is a lot of imported data as well 
(roads, landuse, buildings), as well as in France (landuse, buildings). 
On the other hand, Germany and the UK have relatively small amounts of 
imported data.


Referring back to your earlier question: there is open data, and there 
is open data. The degree of openness is varying. The most open 
datasets are the public domain datasets (PD, CC-0). Federal Canadian and 
US datasets are examples of that, like Canvec. Any license attached to 
the open data in fact restricts its usage. Each restriction needs to 
be evaluated carefully. Before importing any open dataset, one must 
make sure that those restrictions can be honored to.  So, a license like 
CC-BY-SA imposes that the author should be attributed (BY-clause), and 
that the data can only be shared under a similar license (SA-clause). It 
is difficult for OSM to do the attribution part, because the objects 
themselves can easily be edited. Sharing alike is out of the question 
with the ODbL, as this is a completely different license (although with 
similar clausess). And of course other guidelines are that it should not 
replace user-contributed data (unless widely agreed upon), that it is 
maintainable, etc.


Of course there is a way out when the license seems to be 
incompatible, namely contacting the author, and ask if they are prepared 
to grant you a license to have it incorporated under the OSM-license 
(ODbL). They own the copyright to the data, so they have the authority 
to decide on that. You can see the (too restrictive) license as an 
invitation for negotiations for the data owner to open up a bit more ;) 
This is the way how a lot of the listed datasets in the catalog ended up 
being imported in OSM. Of course, when you receive authorization, it 
should be listed on the wiki page describing the import as well, so it 
can be referred to later as well. This is also the place where the 
original author can be attributed to.


When it comes to the question whether imported data is good or not: 
there is no clear cut answer to it. Sometimes it can be good, but all 
too often it ends up badly. Those kinds of imports are the main reason 
why imports in general have not a good name. See for example 
http://worstofosm.tumblr.com/ . Have a laugh about it :) BUT, if you 
intend to import data, make sure your import doesn't end up at that place!


I hope this clears up some of your concerns.

Cheers,

Frank

On 31-7-2012 19:04, Bruno Remy wrote:



2012/7/31 Richard Weait rich...@weait.com mailto:rich...@weait.com

2012/7/31 Bruno Remy bremy.qc...@gmail.com
mailto:bremy.qc...@gmail.com:
 Thanks Richard for your considerations.

 While reading your comments, I'm carried to believe that :
 wheras Canadian municipalities produce scrap data versus
europenan ones

I don't believe this.

 Canadian citizen are less confident in theyr gouvernement's IT
stuff than
 European does.

I don't believe this either.

OSM in Europe has grown more effectively than in North America,
because there are more _OSM contributors_ in Europe.  Not because
there is more Open Data in Europe.  Much less data has been imported
in Europe than in North America.


I totally agree with you about the number of contributors in Europe 
versus in North America.
But I don't see clear correlation between number of contributors and 
number of data (ways, nodes.) because only 38% of contributors 
doesn't edit data, and only 19% make recuring edits.

(source = http://www.mdpi.com/2220-9964/1/2/146)

In the facts, most of main ways (coastlines, cities, roads, 
administrative boundaries) provides from Datasets mentionned here  
(http://wiki.openstreetmap.org/wiki/Import/Catalogue) But if you take 
the time to analyse this import catalog 
http://wiki.openstreetmap.org/wiki/Import/Catalogue, it's clear that 
*mostly all datasets are provided by European* organisations (*only 
14%* from North-America).

So, YES Europe has more date but MOSTLY because of import of dataset.

*For sure, contributors maintained and enhanced acuracy of these 
data*... but nobody can imagine that every single house and every 
single road has been handmade by volunteered geographic information 
(VGI):



In this context, if I introduce new mappers to OpenStreetMap as you 
said, *by telling them drawing manualy 

Re: [Talk-ca] opendata datasets

[Frank Steggink]

On 31-7-2012 15:09, Bruno Remy wrote:

Does this Quebec city Opendata Licence compatible with OSM? (Y/N) And Why?
http://donnees.ville.quebec.qc.ca/licence.aspx


I'll give this a try with my understanding of French, so be aware... ;) 
I'll only pay attention to the clauses which might be an issue for an 
eventual import in OSM.



2. Droits de propriété intellectuelle

2.1 La Ville conserve tous les droits de propriété intellectuelle à 
l’égard des Données et vous reconnaissez que vous n’avez aucun droit 
de propriété intellectuelle, incluant les droits d’auteur, sur les 
ensembles de Données. Si vous rendez les ensembles de Données 
accessibles à un tiers en octroyant une sous-licence, en format 
original ou modifié, vous devez lui fournir une copie des présentes 
conditions d’utilisation pour vous assurer qu’il respecte les 
conditions d’utilisation, sans les modifier.
This means that OSM should inform all third parties about this license. 
How can this be done? And this should only apply to extracts which cover 
parts of Quebec City, and only when it includes City data. This is 
difficult with the current infrastructure.



3. Indication de la source des ensembles de Données

3.1 Vous devez inclure et maintenir l'avis suivant sur toute 
reproduction des ensembles de Données :


« Contient des données reproduites et distribuées « telles quelles » 
avec la permission de la Ville de Québec. ».

Same issue as 2.1



3.2 Si vous développez une application qui contient, en tout ou en 
partie, des Données de la Ville, vous devez inclure l'avis suivant sur 
cette application :


« Cette application contient des données ouvertes accordées sous 
licence « telles quelles » aux termes d’une licence d'utilisation des 
données de la Ville de Québec. L'octroi de la licence ne constitue pas 
une approbation de l’application par la Ville de Québec. »


ou tout autre avis approuvé au préalable par écrit par la Ville.
Same issue as 2.1 + we can't control any applications users of the OSM 
dataset apply. For reasons like this the import catalog has been set up, 
including the pages describing each import.



4. Modifications des ensembles de Données ou des conditions d’utilisation

La Ville peut apporter en tout temps des modifications concernant les 
ensembles de Données ou les conditions d’utilisation. Le cas échéant, 
un avis de modification peut être publié sur la page d’accueil des 
ensembles de Données ou sur la présente page. Sauf indication 
contraire, toute modification entre en vigueur dès la publication de 
l’avis.
This means that the City government can change the license. Although 
this only applies after data which has been obtained from their site 
after a certain date, OSM should state that the used data has been 
obtained before that particular date. To avoid any misunderstandings, 
special permission would be much better.


5.2.1 la Ville ne peut assurer qu’aucun tiers ne détient de droit 
d’auteur, droit moral ou autre type de droit de propriété 
intellectuelle à l’égard des ensembles de Données;
Whoops! What happens if a third party claims copyright about imported 
data? Even with written permission from the City, this remains an issue.



7. Annulation de la licence en cas de non-respect

La Ville se réserve le droit de résilier ou de suspendre votre licence 
d’utilisation aux ensembles de Données sans avis ni délai si elle 
estime que vous ne respectez pas les conditions d’utilisation, que 
vous contrevenez à la loi ou que vous portez préjudice à autrui. Le 
cas échéant, vous ne serez plus autorisé à utiliser ni à reproduire 
les ensembles de Données. Vous demeurez toutefois lié par toute 
entente de sous-licence que vous avez conclue dans l'exercice de vos 
droits aux termes de la présente licence avant la résiliation.
This means we can't just import the data under their own license, 
because we have no guarantees that the City thinks we respect their 
license terms.



8. Lois et juridiction applicables

La présente Entente et les droits des parties sont interprétés, 
appliqués et régis en conformité avec les lois en vigueur de la 
province du Québec et les lois du Canada, le cas échéant. Tout litige 
relatif à l’interprétation, l’application ou l’exécution de la 
présente licence ou de l’utilisation des Données devra être tranché 
par les tribunaux compétents siégeant dans la province de Québec.
OSM is an international project, so this might be an issue, albeit 
theoretical, since most users of Québec data (city/province) will likely 
be from Canada.



Conclusion: based on their license terms, I would say that this data 
cannot be imported into OSM, without an additional license. Clause 5.2.1 
remains a problem though, and I can imagine that this could be a reason 
not to grant special permission to OSM at all. On the other hand, this 
can (should!) be addressed in an eventual request, explaining the role 
of the OSMF and the Data Working Group.


Regards,

Frank

Re: [Talk-ca] Noms autochtones

[Frank Steggink]

Quoting Fabian Rodriguez magic...@member.fsf.org:


On 07/17/2012 06:38 PM, Bruno Remy wrote:


bonjour,

Avez-vous déjà pensé à l'indication des lieux autochtones? Il y en a
beaucoup à travers le Canada et comment les intégrer à nos
cartographies à tendance francophones ou anglophones dans nos
différentes provinces?

Bruno Remy



Pour quelle langue(s)? Je suppose que tu penses surtout à l'attribut
name? Il a une extension, par exemple pour un parc qui aurait un nom en
inuktitut ou mohawk tu utiliserais le code ISO-639-1.2 correspondant:
name:iu=XX
name:moh=XX
sans oublier
name:en
name:fr

Cette page l'explique bien, peut-être bénéficierait-elle d'une section
pour le Canada:
http://wiki.openstreetmap.org/wiki/Bilingual_street_names

A+

Fabian Rodriguez
http://openstreetmap.magicfab.ca



Salut,

Au Village-des-Hurons à Québec j'ai ajouté des noms huron (Wyandot)  
aussi. Voir ici: http://osm.org/go/cKZkGCh9L-- . J'ai utilisé le code  
ISO 'wya' pour les noms autochtones.


Par example: http://www.openstreetmap.org/browse/way/33724586

Frank


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

Re: [Talk-ca] How did you start in OSM?

[Frank Steggink]

On 6-7-2012 13:27, Richard Weait wrote:

Do you remember how you first heard of OSM, or first got mapping?

I think the first sign I saw of OSM was in a post on slashdot in June 2006.

Share your story.  How'd you get started?

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

I probably heard for the first time about OSM years ago on the 
PlanetGS.com blogroll. It must be around 2005 / 2006. There were talks 
about mapping parties at the Isle of Man and later Isle of Weight in the 
United Kingdom. At that time I would think it would be nearly impossible 
to create a worldwide street map. Later I went to the FOSS4G conference 
in Vancouver, and talked with some guys about it. I would swear James 
Ewen was one of them, but the conference was in 2007. As the project 
grew, I became more interested :)


Anyways, in spring 2008 I got my old GPS (which I've used for 
geocaching, but only a few times), and went exploring the area around 
Quebec City, where I was living at that time. Being Dutch but living 
abroad, I didn't have a big social network. So, being a mapping geek OSM 
was a great way to explore the environment where I was living.


Frank


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

Re: [Talk-ca] Tr : [OSGeo-qc] Données ouvertes : gouvernement du Québec...

[Frank Steggink]

Nicolas, thanks a lot for the data and the information!

Of course the first page I went to was the License page: [1] 
Unfortunately this license doesn't seem to be compatible with any of the 
current OSM licenses (neither CC-BY-SA nor ODbL). The reason is that the 
license states that it it non transférable (non-transferrable). Also 
the Province of Quebec reserves all intellectual property rights to this 
data: L’Administration gouvernementale conserve tous les droits de 
propriété intellectuelle à l’égard des données ouvertes... When the 
data would be uploaded into OSM, it would be inevitable that the data 
gets modified somehow, due to the fact that this is a crowdsourced project.


An option for OSM would be to get some special agreement that we can use 
this data under our own conditions. I don't know if this would be 
realistic. Nicolas, could you give your view on it, as an employee of 
the provincial government? What would be the best venue to come to some 
agreement? Are there any other options?


On the other hand: weren't the administrative boundaries of Quebec 
scheduled for inclusion in a future release of Canvec? Probably the 
Government of Quebec and NRCan have some kind of agreement on this.


Frank

[1] http://donnees.gouv.qc.ca/?node=/licence

On 30-6-2012 5:33, Nicolas Gignac wrote:
Pour votre info, il y a des données géographiques administratives sur 
le site de données ouvertes du Qc, voir ce jeu de données :

http://donnees.gouv.qc.ca/?node=/donnees-detailsid=d6c535cb-b508-4cab-9a15-bdccd9433da4
Sur la page de téléchargement, voir la section *Découpages 
administratifs**(mise à jour mai 2012)* :

http://www.mrnf.gouv.qc.ca/territoire/portrait/portrait-donnees-mille.jsp
Évidemment, l'échelle de cette donnée est au 1 : 1 000 000.

Au plaisir,

Nicolas

Le 29 juin 2012 16:50, Pierre Béland infosbelas-...@yahoo.fr 
mailto:infosbelas-...@yahoo.fr a écrit :


Je fais suivre le courriel de Nicolas Gignac adressé à la liste
OSGeo-qc concernant le nouveau site de données ouvertes du
gouvernement du Québec. Nous ne retrouvons pas les données de
limites administratives (ville, MRC, régions administratives).
Pourquoi ne pas les demander?

I forward the email sent to the OSGeo-qc list byNicolas Gignac
relatively to the Government of Québec Open Data site newly
created. We do not find the administrative boundaries data (city,
RCM, administrative region). Why not ask?

Pierre

- Mail transféré -
*De :* Nicolas Gignac gignac...@gmail.com
mailto:gignac...@gmail.com
*À :* OSGeo-Quebec que...@lists.osgeo.org
mailto:que...@lists.osgeo.org
*Envoyé le :* Vendredi 29 juin 2012 15h17
*Objet :* [OSGeo-qc] Données ouvertes : gouvernement du Québec...

Pour votre info, le site de données ouvertes du gouvernement
du Québec est maintenant officiellement en ligne depuis hier :
http://donnees.gouv.qc.ca http://donnees.gouv.qc.ca/
La partie géomatique du site :
http://donnees.gouv.qc.ca/?node=/applications-geomatique est
supportée par le projet GOLOC qui intègre OpenLayers / GeoExt
et les couches WMS sont diffusées par UMN MapServer. Des
données brutes sont également disponibles en format Shapefile
et KML.
L'url du getcapabilities pour le WMS qui inclue certaines des
données ouvertes géographiques est le suivant :

http://geoegl.msp.gouv.qc.ca/cgi-wms/gouvouvertqc?request=getcapabilitiesservice=wmsversion=1.1.1

Le site web en tant que tel est supporté par du code en JQuery
/ Php, avec un service de catalogue normé (Catalog Service for
the Web) :
http://en.wikipedia.org/wiki/Catalog_Service_for_the_Web
supporté par le projet international GeoNetwork
(http://geonetwork-opensource.org/), une base de données
PostgreSQL (www.postgresql.org/ http://www.postgresql.org/)
et ses fonctionnalités PG de full text searching comme
tsvector et trigram pour la recherche du catalogue, tout
cela est monté sur deux serveurs Linux : OpenSuse et Ubuntu
Server ( pour GeoNetwork).

Si vous avez des données géographiques que vous aimeriez voir
sur le site de données ouvertes produites par le gouvernement
du Québec et qu'elles ne s'y retrouvent pas, veuillez faire
une demande de données en utilisant le formulaire disponible
en ligne sur le site :
http://donnees.gouv.qc.ca/?node=/demande-donnees


Au plaisir,

Nicolas

___
Quebec mailing list
que...@lists.osgeo.org mailto:que...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/quebec





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

Re: [Talk-ca] CBC English; no - françias; oui

[Frank Steggink]

On 30-5-2012 18:41, Bruno Remy wrote:

Hi folks!

Here from Quebec city (Qc) we're starting a local OSM group of mapping 
users and contributors.

Hope we'll have fun and a lot of mapping partys !

At first, we'd like to exchange working expriences with the gang of 
Toronto saw recently on CBC-Radio-Canada news.

Is there anybody here from Toronto ? (John Robb.Steve Singer, or )

Thanks,
--
Bruno Remy
OSM Québec


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

Hi Bruno,

Great initiative! I'll try to follow it, albeit not closely. Just about 
6000 km nowadays. ;) Will there be a mailing list or something? French 
is not an issue.


Regarding work in the area: have a look at residential areas which are 
built after 2009. Perhaps a couple of other roads have changed names in 
the meantime. Also the info from the RTC was released under an open data 
license a while back. Maybe it could be use to add more bus lines to 
Quebec City. And of course the Bing imagery in the area is great, which 
could be put to good use as well :)


There is also some work to be done to the Geobase roads which were 
imported in 2009 (by me or others). Those don't have names. It's still 
on my list to do something about it (by either copying the names from 
the latest Canvec roads, or replace them altogether if they aren't 
edited since the import), although I must admit that it has sunken to 
the bottom.


Anyways, it's great to hear that a real community is growing at last :) 
I wish you guys a lot of succes!


Frank

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

Re: [Talk-ca] Quebec's Bermuda Triangle

[Frank Steggink]

On 10-4-2012 21:53, Pierre Béland wrote:

Harald,
It probably mean that this have been corrected already but that tiles 
have not been updated yet for all zoom levels. I often see that when a 
erase a feature, updates can be made rapidly at some zoom levels and 
not at others. And after a day or two, the edit is completed for all 
levels.

//
/Pierre/

*De ：* Harald Kliems
*Date/heure ：* 2012-04-10 14:25:08
*A ：* Talk-CA OpenStreetMap
*Cc ：*
*Sujet ：* [Talk-ca] Quebec's Bermuda Triangle
Hi everyone:
a while ago I noticed this weird triangle west of Vaudreuil:
http://www.openstreetmap.org/?lat=45.342lon=-74.24zoom=9layers=M
If you zoom in any further it disappears. I initially thought it was
some coastline-related flooding issue but since it doesn't extend all
the way to the Ottawa River that seems unlikely. I've opened the
region in JOSM and couldn't find anything that might render as this
weird triangle. Maybe someone will have luck in uncovering its secret.
Best,
Harald.
--
Please use encrypted communication whenever possible!
Key-ID: 0x199DC50F
___
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
The triangle is probably caused by the shapefile which is used for 
rendering the coastline at levels 9 and below. This shapefile isn't 
updated very often. I believe it is a different one than the file used 
for levels 10 and above, which should be updated about once a week.


Frank

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

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

[Frank Steggink]

On 31-3-2012 7:25, Richard Weait wrote:

Okay, so, u.  Wow!

I've been looking around with the OSM Inspector to see how the license
clean up is progressing elsewhere.

You've been busy.

Victoria and Nanaimo looked pretty dire a few weeks ago.  They're in
much better shape now.  Southwestern Ontario looks great. The Niagara
peninsula and Golden Horseshoe look good.  Toronto and environs has
some minor issues still, but is much improved. All of that is super to
see.

There are some spots that could use your attention if you still have
some cleaning cycles before Sunday.  Ottawa, Montreal, Quebec, Sydney,
Fredericton and Sherbrooke could use some help. There is some
coastline to be cleaned near Sept-Iles.  Winnipeg and Brandon would
like your help.  Yorkton, up to Saskatoon and Lloydminster need some
love.  Edmonton, Red Deer and Calgary would benefit from your
attention and there are still some areas near Whistler to improve.

If you are feeling some cross-border love, perhaps you'll help our
lake-mates with the US side of the Great Lakes?  The area near Sault
Sainte Marie should be looking better. Lake Ontario seems good as does
most of Erie.

Help out some more, if you can.  You've done a super job of sorting
out a lot of data.  That's great to see.  Be proud of yourselves.  :-)

If you haven't been using OSMI to help clean up, you should.  Have a
look.  Sorry for the long link.

http://tools.geofabrik.de/osmi/?view=wtfelon=-75.24686lat=45.17431zoom=7opacity=0.41overlays=overview,wtfe_point_clean,wtfe_line_clean,wtfe_point_harmless,wtfe_line_harmless,wtfe_point_inrelation,wtfe_line_inrelation_cp,wtfe_line_inrelation,wtfe_point_modified,wtfe_line_modified_cp,wtfe_line_modified,wtfe_point_created,wtfe_line_created_cp,wtfe_line_created

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


Hi Richard,

Working on Quebec. I've replaced about half of the affected roads with 
Canvec. The stray non-ODBL nodes (which happen to be along main streets) 
are due to nodes being reused for landuse. I'm not sure if those can be 
cleaned up in time (as I expect to be busy with the rest of the roads 
most of the day), but I'll try.



Frank

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

Re: [Talk-ca] canvec data offset

[Frank Steggink]

I've seen some of these deviations as well during Canvec import. Because 
they are so small ( 1 meter), I just decided to glue the polygons 
together, so any slivers are gone.


It is inconvenient though. Could it be related to that some sheets were 
originally still in NAD27, instead of NAD83 (which is approximately 
WGS84, as used by OSM)?


Frank

On 31-1-2012 15:06, michael bishop wrote:

the south east corner of 021O10.0 is at 47.534 by -66.7500013
the north east corner of 021O07.1 (should be exact same node), is at 
47.500 by -66.750
the exact offset differs from corner to corner, some are off more then 
others, some are off in a different direction



On 01/31/2012 08:11 AM, Bégin, Daniel wrote:

Bonjour,

I'll have a look to see if I can do something for it in the next 
release.


I suspect that might be caused by data resolution. Lat and Lon are 
stored in decimal degrees with 7 digits precision (48.1234567). The 
7th digit will provide a precision around 0.001 meter. The 6th digit 
a precision around 0.027 meter witch look like your 0.03 meter.


Cheers
Daniel

-Original Message-
From: michael bishop [mailto:cle...@nbnet.nb.ca]
Sent: January 30, 2012 16:11
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] canvec data offset

ive been working with canvec for a few days now, and ive noticed some 
of the data is offset by 0.03 meters its not matching up with nearby 
tiles


for example 021O10 doesnt match up with 021O07

ive noticed the problem on other tiles aswell, but didnt think to 
write them down



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




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




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

Re: [Talk-ca] User r_coastlines

[Frank Steggink]

On 19-12-2011 20:38, john whelan wrote:
Yes because it is the individual contributor who has to accept the 
OSM's new licensing terms, the data was not imported directly from 
CANVEC into OSM.


As a Canadian tax payer I'm not quite certain I like the idea of OSM 
having the power to re-license Government data but that is a separate 
issue.



John,

Whether you like it or not, NRCan explicitly allows it, as long as they 
are attributed as the source:


/All distributed data should be accessed and used relatively to the 
GeoGratis Unrestricted Use Licence Agreement 
http://geogratis.cgdi.gc.ca/geogratis/en/licence.jsp. With this 
licence, users are granted a non-exclusive, fully paid, royalty-free 
right and licence to exercise all intellectual property rights in the 
data. This includes the right to use, incorporate, sublicense (with 
further right of sublicensing), modify, improve, further develop, and 
distribute the data; and to manufacture and/or distribute Derivative 
Products. The Licensee shall identify the source of the Data, in the 
following manner, where any of the Data are redistributed, or contained 
within Derivative Products: © Department of Natural Resources Canada. 
All rights reserved.

/
See: http://geogratis.cgdi.gc.ca/geogratis/en/index.html

Furthermore, NRCan is even spending your tax dollars to facilitate 
incorporating their data into OSM.


Personally, as a former Canadian tax payer I can say that what NRCan 
does is one of the best ways of my tax dollars being spent :) It's too 
bad that the national mapping agency which is currently being funded by 
my tax euros takes a way less proactive stance towards open data. At 
least by decree of our Ministry of Economy, Agriculture and Innovation, 
a lot of geospatial and other data will be open in a few weeks :)


Every time when your government is doing something you don't like, are 
you going to share that with the world as well?


Frank

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

Re: [Talk-ca] User r_coastlines

[Frank Steggink]

On 19-12-2011 18:57, Andrew Allison wrote:

Hello:
Unless I'm missing something or it's a bug Using the OSM Inspector
tool. The coastline data as going to be removed, or at least a
significant amount.

http://tools.geofabrik.de/osmi/?view=wtfelon=-81.24969lat=42.97091zoom=13overlays=overview,wtfe_point_harmless,wtfe_line_harmless,wtfe_point_modified,wtfe_line_modified_cp,wtfe_line_modified,wtfe_point_created,wtfe_line_created_cp,wtfe_line_created

There is a lot of data being flagged by users who haven't been around
in years. Sigh

Andrew


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


Hi Andrew,

I'm not sure, but r_coastlines only shows up as a value for the 
created_by tag, which is a deprecated tag for programs / scripts to 
edit/import data in OSM. The PGS coastline data import doesn't seem to 
be assigned to a user. So, I would say that this data will remain in 
OSM, although I don't know for sure if this is true. The data itself 
comes from the US NGA, so it is Public Domain. See [1] for details.


The link you're showing, isn't showing coastlines, but data from London, 
ON, which has been contributed by RogueGPSer. He has (indeed) not 
decided about relicensing. [2]


Regards,

Frank

[1] http://wiki.openstreetmap.org/wiki/PGS
[2] http://www.openstreetmap.org/user/RogueGPSer

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

[Talk-ca] Canvec source tags (was: User r_coastlines)

[Frank Steggink]

On 19-12-2011 22:20, john whelan wrote:
But recently I noted that the CANVEC tags are being removed.  Two 
people in the talk-ca list mentioned recently they had done so.


Cheerio John
According to my mailbox the answers were different. Jonathan mentioned 
that he used other data sources, so the data wasn't significantly Canvec 
anymore. Gordon didn't mention he removed tags, he just offered a 
possible reason. As to your question in that thread, and not knowing the 
user you were referring to, I was just wondering whether you sent 
him/her a PM and asked about the reason (but I didn't bother to post 
that to the mailing list). So, did you ask that user directly?


Also Bing has stated that they should be attributed. That is one of the 
conditions they provided their imagery to OSM. Of course everyone knows 
that the source tags aren't absolute guarantees. It is also not 
practical to enforce them. If that would happen, OSM would not develop 
as it does right now, so although I would oppose removing source tags 
knowingly (when the data is not altered significantly), there are many 
shades of grey. It is often hard to draw a boundary, so we have to rely 
on the good intentions of the mappers. That makes a project like OSM 
both challenging and charming :)


Regards,

Frank

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

Re: [Talk-ca] Canvec source tags

[Frank Steggink]

On 19-12-2011 22:40, Frank Steggink wrote:

On 19-12-2011 22:20, john whelan wrote:
But recently I noted that the CANVEC tags are being removed.  Two 
people in the talk-ca list mentioned recently they had done so.


Cheerio John
According to my mailbox the answers were different. Jonathan mentioned 
that he used other data sources, so the data wasn't significantly 
Canvec anymore. Gordon didn't mention he removed tags, he just offered 
a possible reason. As to your question in that thread, and not knowing 
the user you were referring to, I was just wondering whether you sent 
him/her a PM and asked about the reason (but I didn't bother to post 
that to the mailing list). So, did you ask that user directly?


Also Bing has stated that they should be attributed. That is one of 
the conditions they provided their imagery to OSM. Of course everyone 
knows that the source tags aren't absolute guarantees. It is also not 
practical to enforce them. If that would happen, OSM would not develop 
as it does right now, so although I would oppose removing source tags 
knowingly (when the data is not altered significantly), there are many 
shades of grey. It is often hard to draw a boundary, so we have to 
rely on the good intentions of the mappers. That makes a project like 
OSM both challenging and charming :)


Regards,

Frank


John,

I've got a question for you. I'm planning to (finally) clean up the 
forests / residential areas in Quebec City for some time. [1] I'll 
probably do this around Christmas. For this task I'll rely on the Bing 
imagery. How should I tag the polygons I create / modify? Should I leave 
Canvec intact as a source, use Bing, or should I cut up the polygons 
in two? The only difference between the new parts will be the attribution.


I usually use a mixed tag in such cases (like source=Canvec;Bing). But 
since OSM has many users, many which are not experienced and/or do not 
care about these issues, can you realistically expect that everyone will 
take care about attribution properly?


Regards,

Frank

[1] http://osm.org/go/cKZOMVgi-

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

Re: [Talk-ca] import complaints

[Frank Steggink]

On 4-12-2011 15:22, Steve Singer wrote:

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


Richard,

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


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


In particular

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


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


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


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


Steve





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


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

dear all,

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

Best regards,
Richard

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

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




___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
Steve, thanks. I've moved the warning to a more prominent place, to the 
summary at the top. Otherwise (new) readers might miss it too easily.


Frank

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

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

[Frank Steggink]

On 25-11-2011 16:04, Richard Weait wrote:

Dear All,

The London hack weekend starts in a few hours in London (yay!),
England (oh.)  One of these days I'll organize a hack weekend in
London, Ontario, just for laughs.

Interesting things come out of these hack weekends and sometimes we
see the results right away, like squashed bugs or new tools, and other
times the changes are rolled out on a schedule.  The OSM API change
from 0.5 to 0.6 was largely decided at a previous hack weekend, then
rolled out as scheduled during server maintenance if I recall
correctly.

So, I'm looking forward to interesting things coming out of the hack
weekend.  You might enjoy watching the dev irc channel if you want to
follow some of the discussions going on at the hack weekend, but
really, you have to be there to get the full benefit.

Two new things have appeared on OSM.org in the last two days, before
the hack weekend even started.

Today, the layer selector (the blue + top right of the map) was
changed.  The seldom-updated nonames layer was removed, and two new
layers were added.  The Transport map shows public transportation
infrastructure, and the Open MapQuest map is a general purpose map.
We want more people to understand you can make special purpose maps
from the same OSM data.

Yesterday, a new version of Potlatch2 was provided on the site.
You'll know that you are using the new version when you realize that
you have been using the map zoom buttons on the top left, rather than
their previous top right location.  I didn't even realize that it was
a change when I first saw it.  :-)

Best regards,
Richard

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


Hi Richard,

Due to the use of Natural Earth (?) as a base layer, certain artifacts 
from the Canvec import become more visible, especially at the lower (= 
7) zoomlevels. See for example the coastline issues in Atlantic Canada: 
http://www.openstreetmap.org/?lat=45.31lon=-63.13zoom=7layers=T . 
Perhaps unintentional, but this rendering can help us a lot cleaning up 
after certain imports. So, I hope this rendering won't be adjusted 
soon... :)


During the import I also strongly suspect that the Canvec data contains 
railroads which do no longer exist. For example, in Québec a part of 
them have been converted to cycleways. Perhaps someone with good 
knowledge about those cycleways can retag them.


Regards,

Frank

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

Re: [Talk-ca] Unexperience user?

[Frank Steggink]

Hi Daniel,

I just had contact with him yesterday after I noticed the incorrect 
rendering. He responded quickly. I asked him whether he was aware of the 
problems, and if he could use some help. He has seen the flooding and 
reverted some of the changes yesterday, notably the broken coastline 
northeast of Ile d'Orleans. He wanted to tag the coastline of the. St. 
Lawrence as a riverbank, so it would show up properly (as a blue area). 
This is a known issue with mkgmap. He will leave the riverbank tag 
upstream of Ile d'Orleans, but has reverted the other errors. Most 
notably the multipolygon for the St. Lawrence he made has been removed 
again. In this multipolygon Ile d'Orleans was tagged as natural=land, 
which caused it to be rendered white (because natural=land is one of 
the topmost styles). I've quickly checked his changes, and the coastline 
seems to appear all right. I still need to do a bigger check.


So, currently the St. Lawrence is tagged both as natural=coastline and 
waterway=riverbank between Quebec City and (at least) the St. PIerre 
lake. Would that be a problem? For the rendering it should work nice, 
but having duplicate / complimentary tagging should be avoided. I'd like 
to propose to use the natural=coastline from downstream Quebec, and use 
waterway=riverbank upstream. Right now Alain has drawn this boundary 
just east of Quebec City. I'd rather move it towards approximately the 
ferry connection with Levis, since upstream the flood/ebb cycle is much 
less strong.


Here is Alain's full answer:

J'ai vu ce matin après quelques jours n'inactivité, que la rive nord du fleuve, 
de la pointe de l'île d'Orléans à la ville de Baie-St-Paul ne se dessinait pas 
correctement sur OpenStreetMap.

Je crois maintenant avoir enlever toutes les modifications à l'est de la ville 
de Québec, y compris l'île d'Orléans et les deux rives du fleuve.

Cependant cela ne corrige pas l'erreur. Peut-être, comme tu l'indiques dans le 
deuxième courriel, est-ce à cause de la mise-à-jour qui ne se fait qu'à tout 
les mercredi.

Mon but était de tagger waterway=riverbank jusqu'à l'est de l'île d'Orléans, 
endroit ou la marée est supposée se manifestée (?). Le reste de l'estuaire du 
fleuve peut demeurer avec natural=coastline c'est vrai qu'il est très large. 
Cependant, à ma connaissance, lorsque les rives du fleuve sont marquées comme 
natural=coastline, le fleuve se dessine comme natural=land sur les gps-garmin 
lorsque passé à travers le logiciel 'mkgmap'.

J'ai essayé de modifié les fichiers de Style, les fichiers '.TYP', mais sans 
résulats. Mais en marquant les rives du fleuve avec waterway=riverbank, et en 
inscrivant les rives dans un multi-polygone, comme indiqué dans la 
documentation, ils ressortent correctement sur les Gps Garmin et le logiciel 
QLandKarteGt.

Je pensais bien avoir pratiquement terminé mes modifications, mais cette erreur 
me complique la vie. Je ne parviens pas à la cerner.

Ton aide serait la bienvenue !

Regards,

Frank




On 11-11-11 09:47 PM, Daniel Begin wrote:


Hi all,

A month ago I found a lot of messy multipolygons having 
natural=coastline and/or waterway=riverbank mixed all together in 
Montreal area, resulting in bad rendering ... 
http://www.openstreetmap.org/?lat=45.295lon=-73.005zoom=9layers=M


All came from user - http://www.openstreetmap.org/user/Alain512. I 
contacted him in mid-October but haven't received any answer yet. 
 Since, other users and I have tried to correct the problems.


He is now working around l'Île d'Orleans near Québec city and I have 
found the same kind of problem... 
http://www.openstreetmap.org/?lat=46.977lon=-70.9076zoom=12layers=M


Is someone else could try to contact him to make sure he understands 
what is doing before continuing...


Regards,

Daniel


___
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] Unexperience user?

[Frank Steggink]

Hmm, regarding the tagging of the St. Lawrence: the Great Lakes should 
still be tagged as natural=coastline, otherwise they'll disappear at 
zoomlevel 5 and upwards. The St. Lawrence itself is barely visible, so 
that shouldn't be a problem. However, the tagging of big lakes in 
general is another topic, which has been discussed before.


Frank

On 11-11-11 10:31 PM, Frank Steggink wrote:

Hi Daniel,

I just had contact with him yesterday after I noticed the incorrect 
rendering. He responded quickly. I asked him whether he was aware of 
the problems, and if he could use some help. He has seen the flooding 
and reverted some of the changes yesterday, notably the broken 
coastline northeast of Ile d'Orleans. He wanted to tag the coastline 
of the. St. Lawrence as a riverbank, so it would show up properly (as 
a blue area). This is a known issue with mkgmap. He will leave the 
riverbank tag upstream of Ile d'Orleans, but has reverted the other 
errors. Most notably the multipolygon for the St. Lawrence he made has 
been removed again. In this multipolygon Ile d'Orleans was tagged as 
natural=land, which caused it to be rendered white (because 
natural=land is one of the topmost styles). I've quickly checked his 
changes, and the coastline seems to appear all right. I still need to 
do a bigger check.


So, currently the St. Lawrence is tagged both as natural=coastline and 
waterway=riverbank between Quebec City and (at least) the St. PIerre 
lake. Would that be a problem? For the rendering it should work nice, 
but having duplicate / complimentary tagging should be avoided. I'd 
like to propose to use the natural=coastline from downstream Quebec, 
and use waterway=riverbank upstream. Right now Alain has drawn this 
boundary just east of Quebec City. I'd rather move it towards 
approximately the ferry connection with Levis, since upstream the 
flood/ebb cycle is much less strong.


Here is Alain's full answer:

J'ai vu ce matin après quelques jours n'inactivité, que la rive nord 
du fleuve, de la pointe de l'île d'Orléans à la ville de Baie-St-Paul 
ne se dessinait pas correctement sur OpenStreetMap.


Je crois maintenant avoir enlever toutes les modifications à l'est de 
la ville de Québec, y compris l'île d'Orléans et les deux rives du 
fleuve.


Cependant cela ne corrige pas l'erreur. Peut-être, comme tu l'indiques 
dans le deuxième courriel, est-ce à cause de la mise-à-jour qui ne se 
fait qu'à tout les mercredi.


Mon but était de tagger waterway=riverbank jusqu'à l'est de l'île 
d'Orléans, endroit ou la marée est supposée se manifestée (?). Le 
reste de l'estuaire du fleuve peut demeurer avec natural=coastline 
c'est vrai qu'il est très large. Cependant, à ma connaissance, lorsque 
les rives du fleuve sont marquées comme natural=coastline, le fleuve 
se dessine comme natural=land sur les gps-garmin lorsque passé à 
travers le logiciel 'mkgmap'.


J'ai essayé de modifié les fichiers de Style, les fichiers '.TYP', 
mais sans résulats. Mais en marquant les rives du fleuve avec 
waterway=riverbank, et en inscrivant les rives dans un multi-polygone, 
comme indiqué dans la documentation, ils ressortent correctement sur 
les Gps Garmin et le logiciel QLandKarteGt.


Je pensais bien avoir pratiquement terminé mes modifications, mais 
cette erreur me complique la vie. Je ne parviens pas à la cerner.


Ton aide serait la bienvenue !

Regards,

Frank




On 11-11-11 09:47 PM, Daniel Begin wrote:


Hi all,

A month ago I found a lot of messy multipolygons having 
natural=coastline and/or waterway=riverbank mixed all together in 
Montreal area, resulting in bad rendering ... 
http://www.openstreetmap.org/?lat=45.295lon=-73.005zoom=9layers=M


All came from user - http://www.openstreetmap.org/user/Alain512. I 
contacted him in mid-October but haven't received any answer yet. 
 Since, other users and I have tried to correct the problems.


He is now working around l'Île d'Orleans near Québec city and I have 
found the same kind of problem... 
http://www.openstreetmap.org/?lat=46.977lon=-70.9076zoom=12layers=M


Is someone else could try to contact him to make sure he understands 
what is doing before continuing...


Regards,

Daniel


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



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




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

Re: [Talk-ca] Ping John Whelan?

[Frank Steggink]

On 11-06-07 06:31 PM, Richard Weait wrote:

On Tue, Jun 7, 2011 at 12:24 PM, john whelanjwhelan0...@gmail.com  wrote:

I would be extremely happy to see all my edits removed.

So you are happy to be known as a vandal, in order to ... Why?  That seems odd.

He wants his data removed, and he doesn't care how. It's clear he 
doesn't care about OSM anymore. The internet will be happy to remember 
him as an untrustworthy person in eternity...


Anyways, it's pretty evident he can't be reasoned with, so I hope the 
DWG will take the right actions soon.


Frank

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

Re: [Talk-ca] Railways duplicated in CanVec data

[Frank Steggink]

On 11-06-03 05:30 AM, Samuel Longiaru wrote:


OK... I can set up one dedicated to Canvec imports.  That's no problem 
if that is the preferred practice.   I do remember now reading that 
reference in the Wiki that states  Consider creating a new user for 
the import but I interpreted the reason for doing so as not 
applicable as I was not adding anything to the source tags.  So I did 
what was asked... I considered it... but I didn't do it.  Also, I am 
not blindly or mechanically importing but editing and tweaking as I 
go, so I guess there is a gray area as to what is CanVec and what is 
personal.  I also label all the changesets as CanVec imports so that 
they are more obvious in my own edit history.  But if it makes things 
easier to track... I'll continue from now on under a different account.


Thanks for the guidance.

Sam



-Original Message-
*From*: Richard Weait rich...@weait.com 
mailto:richard%20weait%20%3crich...@weait.com%3e
*To*: Talk-CA OpenStreetMap talk-ca@openstreetmap.org 
mailto:talk-ca%20openstreetmap%20%3ctalk...@openstreetmap.org%3e

*Subject*: Re: [Talk-ca] Railways duplicated in CanVec data
*Date*: Thu, 02 Jun 2011 20:55:06 -0400

On Thu, Jun 2, 2011 at 6:51 PM, Samuel Longiarulongi...@shaw.ca  
mailto:longi...@shaw.ca  wrote:

  What?  Didn't know that.  We should be importing under a separate account?
  How is that to be set up?  Sorry if I've been doing this wrong.

http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account
http://wiki.openstreetmap.org/wiki/Automated_Edits/Code_of_Conduct
http://wiki.openstreetmap.org/wiki/Data_working_group/Mechanical_Edit_Policy

Indeed.  Separate accounts for each import source are the current best
practice.  Not everybody is following this obviously.  No harm in
trying to follow all of the best guidelines.

Having a separate account is advisable, because you don't know what 
could happen to the data. If it for some reason turns out to come from a 
shady source, then it could be reverted much easier if all the imports 
were done with a separate account. Of course there are no doubts about 
the CanVec status.


Another example is the license discussion. If you for some reason are 
opposed to the ODbL and the new CT's, you can still use a second account 
to import CanVec data for example, because you don't own any rights to 
the CanVec data yourself. It is also much friendlier towards other 
users, so they know that any modifications done to the CanVec data in 
OSM aren't in vain, once the old license is abandoned.


Frank

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

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

[Frank Steggink]

On 11-05-30 09:15 PM, Me (Gmail) wrote:

I've been working on improving the Barrie, Ontario area, and I'm
trying to figure out what is going on with/what to do about Lake
Simcoe.

There are multiple CanVec-imported ways that together make up a fairly
detailed, accurate representation of the lake. A single low-detail way
[1] is overlapping these, and obscures the accurate detail in many
places when rendered [2].

[1]: http://www.openstreetmap.org/browse/way/4997263
[2]: http://dl.dropbox.com/u/2398828/lake-simcoe-josm.png

Not having much experience dealing with large or tiled objects in OSM,
my question is if the low-resolution object is serving a purpose, and
whether I should bother editing it so as to not overlap with the
high-detail version, or whether it can just be deleted.


Hi AJ,

The Canvec version is clearly better, so the lowres version can be 
deleted. It was probably one of the features being traced when only 
Landsat imagery was available. In my opinion this cleaning up should 
have been done during the import of the Canvec sheet. Otherwise this 
import gets more characteristics of a bad import (by leaving duplicate 
features), which we should prevent. (Note that there are also some 
people who think that user traced features are always better than 
imported features, but in this case the difference is evident, and 
nobody has bothered yet to trace the shoreline from the Bing imagery.)


What might have caused this is that Lake Simcoe overlaps several sheets, 
so it can't be deleted at once. Wat I usually do is to cut the part of 
the coastline which is overlapping the sheet being imported, and connect 
the existing coastline to the new one. An example of this can be seen in 
the southeast part of Lac Saint-Jean in Québec: [1]. This is also how 
I've dealt with the Saguenay river, and also with the St. Lawrence 
coastline. This can best be done asap, because you never know for sure 
when you continue with the rest. It is a bit more work, but in my 
opinion it's much better than confusing or even annoying others.


Frank

[1] http://osm.org/go/cLD8wZR--


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

Re: [Talk-ca] Railways duplicated in CanVec data

[Frank Steggink]

@Daniel:

I finally got around to add a few more issues to the page mentioned by 
Adam last week. I'm not sure if you or anyone else also encountered 
them, but here they are:


   * Some roads are tagged as highway=unclasified (with one 's').
 These are mostly linking roads, and usually have the name Voie
 (in Quebec)
   * Most, if not all, road names (in highways and address nodes) have
 multiple consecutive spaces.
   * Some buildings are tagged as highway=services (with an 's' in
 the end), usually service stations near motorways.
   * (and another thing: the JOSM validator is complaning that many
 water areas should be reversed)

Another thing I'm missing is names on large rivers, which are added as 
natural=water (multi)polygons. Is there a way to get those names, or 
perhaps would it be possible to generate centerlines (which can be 
tagged with waterway=river; name=*)? I've attempted to draw a few 
centerlines myself, but it's very time-consuming.


I also wonder if there is any sight on an improved release of the Canvec 
OSM product, which has improved many of the known issues of the current 
release. I'm also still thinking about how to deal with road names, and 
Canvec vs. Geobase roads in general in Quebec. It's not clear how to 
proceed with that, especially since the boots on the ground option is 
nearly impossible.


Other than that I'm still very glad with the offerings given by the NRCan :)

Frank

On 11-05-29 03:10 AM, Adam Dunn wrote:

Indeed. In fact, this issue has already been listed on the wiki page:
http://wiki.openstreetmap.org/wiki/CanVec#CanVec_7
:)

Adam

On Sat, May 28, 2011 at 9:06 AM, Samuel Longiarulongi...@shaw.ca  wrote:

I've been importing in south central BC and have noticed that there is a
consistent duplication of railway = rail ways in the CanVec data.  No big
deal as if I forget, it is caught by the validator, but there must be a
glitch somewhere in converting to OSM?

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



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




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

Re: [Talk-ca] OSM data growth in New Brunswick - Help.

[steggink]

Hi Bernie,

You may want to check out the OSM Mapper service from the company ITO World:
http://www.itoworld.com/static/osm_mapper.html

One of the things you can do is to visualize data changes over time.  
I'm not sure if this can cover the entire province, or is limited to a  
lower level.


HTH,

Frank

Quoting Connors, Bernie (SNB) bernie.conn...@snb.ca:


Hello,

I have been asked on short notice to give an OSM   
presentation to some government employees here in New Brunswick.  I   
would like some data or graphics (or video) that shows the growth of  
 OSM data in NB over the past 5 years.  Can anybody help?  My   
presentation is Thursday morning, March 17th.


I am already aware of the 2008 video showing world   
wide OSM contributions and I'll use that if I can't get info   
specific for New Brunswick:

http://vimeo.com/2598878

Thanks in advance,
Bernie.
--
Bernie Connors, P.Eng
Manager - Spatial Data Infrastructure
Land Information Secretariat
Service New Brunswick
Tel: 506-444-2077 Fax: 506-453-3898
45°56'25.21N, 66°38'53.65W
bernie.conn...@snb.camailto:bernie.conn...@snb.ca
www.snb.ca/geonb/http://www.snb.ca/geonb/







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

Re: [Talk-ca] A present to us

[Frank Steggink]

On 11-02-03 09:14 PM, Richard Weait wrote:

Zoomed in example.

http://open.mapquest.ca/link/6-cO9mOA4Z

I think they've made an improvement in interchange rendering.



Looks good :)
However, I wonder what the (C)2011 MapQuest is doing in the lower 
right corner. Something for Hurricane / Emilie to look at?


Frank

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

Re: [Talk-ca] A present to us

[Frank Steggink]

On 11-02-03 10:18 PM, Richard Weait wrote:

On Thu, Feb 3, 2011 at 4:02 PM, Frank Stegginkstegg...@steggink.org  wrote:

On 11-02-03 09:14 PM, Richard Weait wrote:

Zoomed in example.

http://open.mapquest.ca/link/6-cO9mOA4Z

I think they've made an improvement in interchange rendering.



Looks good :)
However, I wonder what the (C)2011 MapQuest is doing in the lower right
corner. Something for Hurricane / Emilie to look at?

I saw that too, but it was my fault.  I have a script blocker, and had
to allow more scripts to run, and fill in the rest of the attribution.

;-)


Yep, allowing mapquest.co.uk did the trick.
Bit confusing...

Frank

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

Re: [Talk-ca] A present to us

[Frank Steggink]

On 11-02-03 10:18 PM, Richard Weait wrote:

On Thu, Feb 3, 2011 at 4:02 PM, Frank Stegginkstegg...@steggink.org  wrote:

On 11-02-03 09:14 PM, Richard Weait wrote:

Zoomed in example.

http://open.mapquest.ca/link/6-cO9mOA4Z

I think they've made an improvement in interchange rendering.



Looks good :)
However, I wonder what the (C)2011 MapQuest is doing in the lower right
corner. Something for Hurricane / Emilie to look at?

I saw that too, but it was my fault.  I have a script blocker, and had
to allow more scripts to run, and fill in the rest of the attribution.

;-)

It also looks as if the US styles is used in some parts of Canada close 
to the border, and vice versa. See southeastern Quebec for example 
(Sherbrooke region). It is even obvious at lower zoom levels: closer to 
the border the road density seems suddenly much higher (tertiary roads 
are shown).


MapQuest could (and should) use more accurate polygons to clip the 
rendering style. Although I still appreciate MapQuest's contribution / 
attention to OSM, I can't leave this unmentioned ;)


Frank

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

Re: [Talk-ca] Canvec.osm Product -Completed!

[steggink]

Salut Daniel,

Thanks for the great work. Yes, I'm still following the Canvec  
progress. Maybe I'll upload some of the Quebec City area sheets :)


Regarding toponyms, for the Dutch landuse import we had a similar  
issue. It wasn't that natural=land is hiding other features, because  
it's painted on top (that should be logged in trac, b.t.w.). The old  
landuse data (part of the AND import, which mostly contained the road  
network) has some information, like names, which we would like to keep.


For this we used a toponym tag, like toponym=forest, toponym=park,  
toponym=cemetery. There isn't a concrete proposal for it, although  
I've considered writing it for quite a while now. (There is no really  
good alternative, but there are tags like mountain, valley, region,  
and many more to assign names to non-administrative areas.) We just  
use the toponym tag as a way to keep the name in place. The name  
applies to an entire area, so IMHO it isn't correct to replace it by a  
point feature. In addition to it, since all features are considered  
linear features by default in OSM, we put the tag area=yes on it, so  
the name gets rendered in the middle. The name already gets rendered,  
as long as it doesn't collide with other labels.


Cheers,

Frank

Quoting Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca:


Bonjour OSMers!

Canvec.osm Product conversion is completed - except for 31 files   
that should be reprocessed in the following weeks - see the list at   
the end of this email.


What's new ...
- The vegetation has been updated for some areas in eastern Canada.
- Quebec road network now includes addressing;
- Manitoba road network now includes street name;

Schema upgrade ...
- landform=beach replaced by natural=beach - for rendering
- aeroway=runway replaced by aeroway=apron - more realistic
- natural=land area converted to point - unhide features and keeps toponyms
- Some fixme comments were clarified

Identified problems ...
- Tagging error on school/prison that will be fixed on next release.

Cheers,
Daniel

Files not processed
002E13
011D12
012A07
012P08
023G16
023J09
031M08
042J15
042O01
042P12
043B02
043F09
043G03
043G04
043G15
043K06
043L08
043L13
043M01
043N02
043N04
052L15
053J04
053P13
053P14
062F14
063C03
063N07
082G01
083G02
095C14

___
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] Street name upload

[steggink]

Quoting Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca:


Salut osmers,

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


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


Any ideas?

Daniel





Michel's 1337 FME skillz? ;) (He used them for the original Geobase  
import after all.) Or maybe this is a good occasion to charter some of  
the Safe Software guys to help with improving OSM in their own  
country. :)


Frank

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

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

[Frank Steggink]

On 10-08-12 06:27 PM, G. Michael Carter wrote:

 Seems JOSM has a tag on the object called action

node id='20266016' action='delete'






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


Hi Michael,

The action attribute is also used for updates (action='update').
New objects always have a negative ID.

Frank

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

Re: [Talk-ca] Canvec.osm Product almost...

[Frank Steggink]

Salut Daniel,

Yes, I'm still alive :) but unfortunately I can't find much time to 
follow what is going on in Canada. (The import of Dutch landuse data is 
partially to blame ;) ) As you might expect, I've looked a bit at the 
021L14 data (Quebec City area). Here are some comments, and hopefully 
I'm not touching something again which was discussed in the past.

* Some ways are duplicated. They are all hydrological features 
(landuse=basin, landuse=reservoir, natural=water). This is even true for 
the St. Lawrence river.

* I think it would be a good idea to split up each file in 3 files, 
namely one for roads (what one would typically find in the NRN), one for 
hydrological features (as in the NHN), and the rest. The reason is that 
in many areas roads and or hydro features have already been imported (be 
it originally created or Canvec/Geobase based), but this is not true for 
the other features.
-- A consequence of this is that the same node could be found in 
different files. I think that this should be taken care of during the 
import process. As Sam mentions, it is not just 'plopping' the data in 
OSM, but this kind of processing (and also properly connect features 
over tile boundaries, etc.) is also part of it.

* Can you get rid of the turning circles at the end of the roads? I bet 
they are more often non-existing than actually existing.

* Bridges have no layer tags. Probably the actual layer can't be 
determined correctly, but usually it will be layer=1, so that is a good 
default.
-- Regarding bridges: I actually don't like the fact that when a bridge 
crosses a road below it, they both share the same node. This does not 
occur physically. However, if you leave duplicate nodes in there (which 
would throw a wrench in the dedup process), then this might be 
incorrectly be seen as a duplicate node. A workaround could be to give 
one of the nodes a small offset.

* How are you going to deal with the issue I raised in the past about 
huge forest areas? In the sample areas you didn't split up the forests 
into multiple shapes (or multipolygons). OTOH, I don't like to have to 
split up, with the sole purpose to make JOSM more responsive. It might 
be possible that JOSM has improved in this regard as well. (I'm yet 
clueless as to how Potlatch would deal with it.)

* There is an area overlap between several features, like natural=wood 
and natural=wetland. This must come from the source data. I think that 
in this particular case it is justified, namely a wooded marsh/swamp.

Anyways, keep up the good work :)

Thanks,

Frank

On 10-06-17 07:00 PM, Bégin, Daniel wrote:
 Bonjour!
 Before the Canvec.osm production starts, I have produced complete NTS 
 datasets for samples previously offered - actually I have expanded the 
 samples to cover the entire NTS tile and add 092G06.
 Each NTS dataset have been tiled using a quadtree algorithm - a nice 
 example of the result is 092G06 !  The .osm subtiles are zipped all 
 together.  We are still using WinZip but we might eventually move to 
 gzip or bzip.
 Have a look!
 And, by the way, can you make sure everything is still OK with the data?
 Cheers,
 Daniel

 
 *From:* talk-ca-boun...@openstreetmap.org 
 [mailto:talk-ca-boun...@openstreetmap.org] *On Behalf Of *Bégin, Daniel
 *Sent:* 15 juin 2010 15:10
 *To:* talk-ca@openstreetmap.org
 *Subject:* [Talk-ca] Canvec.osm Product almost...

 Bonjour à tous,
 We are still on schedule for Canvec.osm product.  We should be able to 
 start the production later next week.  Each NTS will be tiled using a 
 quadtree algorithm. A tile splits when there is more than 25K nodes in it.
 Each tile is named after the dataset name + tiling subtree.  Subtree 
 naming convention is  0=SW, 1=NW, 2=NE, 3=SE.  Each subtree level is 
 separates with a . - like in 021E05.3.2.1
 Example: 
 http://wiki.openstreetmap.org/wiki/CanVec#Canvec_Product_-_Osm_format
 Regarding splitting threshold, 50K nodes is Osm xapi maximum.  With 
 25K nodes I make sure you can add all the stuff you have/that is 
 already available over the area before uploading it.
 Cheers,
 Daniel


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



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

Re: [Talk-ca] Canvec Product - osm format

[steggink]

Bégin wrote:
 Bonjour tout le monde,
  I've started to document the Canvec.osm product in the wiki.  I'll  
 use the Canvec related pages to do it  
 http://wiki.openstreetmap.org/wiki/CanVec.
  The geometric data model is open for discussion  
 http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model
  The proposed tagging will be updated soon in the corresponding  
 Canvec:* pages
  I'm inviting you to look at the documentation and comment on  
 appropriate discussion pages on via this mailling list.
Hi Daniel,

Interesting text. Few comments:
* I've updated the image. The tags on ways 3 and 5 are not needed,  
since those are the outer ways of multipolygons. I also removed the  
JPEG artefacts (saved as PNG, etc.) and enhanced the color for wooded  
areas. By the way, shouldn't there be a node at the intersection of  
ways 1 and 3?
* I think it is possible to do imports in the fully integrated model  
as well. It isn't necessary to import everything at once, but it could  
be done in multiple iterations.

Regards,

Frank



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

Re: [Talk-ca] Errors importing NRN shapefiles

[steggink]

Hi Bob,

Can you try to add the option -W latin1 ? (the -W needs to be uppercase)
This will take care of the encoding. Probably the default encoding is  
different from the one in the shapefile (which is always latin1).

HTH,

Frank

Citeren Robert Shand b...@shand.org.uk:

 Hi Everyone,

 I'm once again playing with NRN import now that I have more free time.

 I noticed I'm getting some errors importing the shapefile into my   
 gis database

 shp2pgsql -s 4326 NRN_PE_8_0_ROADSEG nrn_roadseg | psql -d gis -f -

 snip

 psql:stdin:16493: ERROR:  invalid byte sequence for encoding   
 UTF8: 0xe96527
 HINT:  This error can also happen if the byte sequence does not   
 match the encoding expected by the server, which is controlled by   
 client_encoding.
 psql:stdin:16494: ERROR:  current transaction is aborted, commands  
  ignored until end of transaction block
 etc. etc.

 Does anyone know how I can fix this error - or will I have to live   
 with that data not making it into my database.

 Thanks

 Bob


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




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

Re: [Talk-ca] canvec mep feature 1150012 10- Coastal water - (Eau côtière) = Ocean - ( Océan )

[steggink]

Quoting Yves Moisan yves.moi...@boreal-is.com:


 I agree with this approach. In the test area I imported I followed the
 procedure you described. There were a few larger river mouths, but
 they were  clearly indicated. Right now I'm getting myself moved back
 to the Netherlands,

 I want to say it out loud on this list : one of the major data
 contributors to OSM for Québec data is .. a great Dutch !  I want to
 thank you for all the OSM work you've been doing for the last two years
 I've known you, that is since you came to our very first Sherbrooke
 mapping party.

 We'll miss you in the field ;-)

 Cheers,

 Yves



Hi Yves and others,

I'm not sure what to say, but compared to many others my contribution  
has been pretty modest. I want to say that I would like to remain  
involved in the Canadian OSM community. Since most is happening on the  
Internet, the physical location doesn't matter much. :) But yes, you  
won't see me crisscrossing Québec anymore ;)

Frank


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

Re: [Talk-ca] PEI is the next coolest province (delayed reaction)

[steggink]

Hi Bob,

Since there was never an agreement from the government of PEI, the  
best thing would be to remove the data from OSM asap, even though it  
looks pretty cool. Making a legally unencumbered geospatial dataset is  
the main goal of OSM, and not just generating pretty maps.

Instead of taking screenshots right before removal, it is also  
possible to render a separate set of tiles. Then this data can be made  
available as an experiment, like what I did with the Quebec  
administrative boundaries a few weeks ago: [1]. I can help you set it  
up if necessary. With this, the PEI government can be approached  
again, so they will still get a sense of how it looks like. Otherwise,  
you can show them the case of Denmark, where all addresses have been  
imported in the entire country.

By the way, glad you mention the new service which visualizes the dupe  
nodes. I've been using it to remove duplicate nodes of the import of  
hydro data in Quebec. It is especially cool that it is updated very  
quickly (lv 7+), so one has a good sense of progress :)

Regards,

Frank

[1] http://mijndev.openstreetmap.nl/~fsteggink/quebec_admin.html

Quoting Robert Shand b...@shand.org.uk:

 Hello everyone,

 I've been looking in the PEI address details lately.

 In July 2009 Peter Rukavina contacted the provincial Government to   
 enquire about the copyright status of the PEI civic address data and  
  to see if they would be willing to open the data up for inclusion   
 into OSM.  Unfortunately shortly after, and before a response was   
 received there was a government reshuffle, and nothing further   
 happened.

 In October 2009 Michel Arsenault contacted Peter regarding the civic  
  address data.  Michel tried contacting the government on several   
 occasions via both email and telephone but unfortunately received no  
  response.  Having not heard back from them Michel prepared the  
 data,  tagged the source for easy removal (just in case anyone  
 contacted  him about the copyright status) and uploaded the data.   
 Michel is  now out of the country and effectively un-contactable  
 until 2011.

 Peter floated the idea to Michel about removing the current data and  
  once again making more official lines of enquiry within government.  
   Michel acknowledged that this was fine, and that he'd considered   
 this with the addition of suitable tags.

 Finally I was investigating dupes ( using this   
 http://www.opengeodata.org/2010/02/08/screencast-on-how-to-remove-duplicate-node-in-openstreetmap/
  ) in   
 PEI

 http://matt.dev.openstreetmap.org/dupe_nodes/?zoom=9lat=46.51269lon=-63.22347layers=BT

 It appears that the majority of the dupe nodes in PEI are the civic   
 address data that has been imported at least twice for Kings County.

 Taking all of the above into account, I propose to the community that

 1) Plenty of cool screenshots of the current OSM map are taken   
 showing the civic address data
 2) The current civic address data is removed due to i) the Dupe   
 nodes and ii) the current unknown copyright status
 3) We approach the government again for suitable licensing terms   
 showing them before/after map shots taken from 1. Trying to prove to  
  them the value of opening the data.

 What does everyone else think?

 Cheers

 Bob

 On 2010-01-28, at 8:13 AM, Robert Shand wrote:

 There was some talk locally about the civic address import.  I'm   
 not sure of the exact status on the copyright. I'll dig through my   
 emails to find out where it got left.

 On 2010-01-26, at 11:47 PM, Sam Vekemans wrote:

 So I was informed today that PEI has already imported the address details.
 Im not sure about the copyright on it.  I did message that user,   
 so to find out more details.
 ie. to contact the government and just ask.


 http://www.gov.pe.ca/civicaddress/download/index.php3

 http://www.openstreetmap.org/?lat=46.16879lon=-63.35656zoom=17layers=B000FTFT

 I remember Richard asking about contacts in PEI, was it regarding this?

 Hopefully the road data will be made available to import.

 According to geobase status, the block face addressing for this   
 province is not yet available.  Is it planned for the near future?
 http://www.geobase.ca/geobase/en/data/nrn/status.html

 Cheers,
 Sam

 Twitter: @Acrosscanada
 Blog:  http://Acrosscanadatrails.blogspot.com
 Facebook: http://www.facebook.com/sam.vekemans
 Skype: samvekemans
 OpenStreetMap IRC: http://irc.openstreetmap.org
 @Acrosscanadatrails
 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ca






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

Re: [Talk-ca] Administrative boundaries of Québec

[Frank Steggink]

Hi Nicolas,

Nicolas Gignac wrote:

 The contact I had in the government of Quebec have raised issues on 
 delivering up-to-date datasets in OSM, such as the Administrative 
 boundaries of Québec (BDGA).
 Could someone help this person to understand quickly the advantage for 
 his organisation to share its data with the OSM community.

I'm not sure if there will be a direct advantage to his organization, 
but making this data publicly available would be hugely advantageous to 
the people of Quebec and others who have interest in it. In my opinion 
this is actually a public service. Administrative boundaries; knowing in 
what territory you are; are an important part of our lives. It is true 
that they already make a generalized version available at no cost, but 
in that case it can't be easily mixed with other data available through 
OSM, today and in the future. This also opens the way for a very broad 
range of possible applications. An example of this are the 
user-generated city maps of maposmatic.org. It is hard to predict what 
will come of it, but I'm sure there are people who will create really 
interesting applications based on this data.

 Here are some of his reserve :
 - He does not want his administration to be wrongly identified as the 
 contributor if someone of OSM edit his data that has been integrated 
 in OSM;

Of all features the history is kept, so it can easily be checked who 
edited the data. When something is wrong, that person should be 
contacted first, and when that can't happen for some reason, the person 
doing the import will probably be contacted, or an e-mail will be sent 
to this list. I don't expect that anyone would contact the government of 
Quebec directly.

 - He does want an attribution somewhere;

The source tag can be used for that. Alternatively, a source tag can be 
added to the changeset at import, although it will be harder to track. 
And of course the organization can be mentioned on the Import/Catalogue 
page in the wiki.

 - He does not want someone to call his administration because their is 
 an error in the data when it was someone of OSM that has edited the 
 data, not his organisation;
 - He is willing to cooperate, but he has issue when users edit his 
 data and his organisation is wrongly identified has the producer.

See above.
And, as Yves mentioned, the data is (currently) licensed as CC-BY-SA, so 
although it originates form him, and there will be attribution (the 
BY-clause), the data can be edited by other persons, as long as those 
changes are released with the same or a similar license (the SA-clause). 
The ODbL license, which is still under development, is of a similar 
nature. That is the idea of open data, (as opposed as making data 
downloadable free of charge.


 Thanks for your help.

 Cheers,

 Nicolas

Regards,

Frank


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

Re: [Talk-ca] Imported Canvec buildings with multiple nodes

[Frank Steggink]

Hi Pierre-Luc,

Are you referring to buildings near Montreal or near Quebec City. In 
both cases buildings have been updated recently. Or are you talking 
about buildings outside of Quebec?
If you would like to know who has uploaded them, you can select a 
building, and view the history. When you enable the data layer in OSM, 
you can even select items from there, review tags, and go to the history.

By the way, no link was included in your mail.

Frank

Pierre-Luc Beaudoin wrote:
 Hi,

 Looking at this map [1], all the buildings that were recently uploaded
 seem to have multiple nodes on the same spot.

 Once again, I can only report this, I don't know the tool or how to
 (efficiently) fix it :)

 Thanks to the one who will be fixing this,

 Pierre-Luc
   
 

 ___
 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] Imported Canvec buildings with multiple nodes

[Frank Steggink]

Hi,

The duplicate building nodes can be (more or less) efficiently fixed 
with JOSM. When you install the Validator plugin (perhaps it's already 
done by default by now), you'll see which nodes are duplicated. The 
simplest way to solve them would be to use the Fix button.

However, generally it is better to be prudent, because a series of 
duplicate nodes indicates that a way is likely duplicated as well. Those 
cases need to be resolved as well. When using the Validator plugin, 
overlapping ways are also detected, but they're considered a mere 
warning. I believe that a way is only considered when the nodes are the 
same. So, you'll either get duplicate nodes or overlapping ways.

In JOSM you can also make a selection (graphically, or using the Search 
form), and when you use the Validator with a selection, only the 
selected elements are being validated. So, you can search for Canvec 
buildings only. NB: it is not possible using boolean operators (the 'OR' 
operator often seems to fail), but you can perform multiple searches in 
a row, and choose how the query should affect the selection (replace, 
add, remove, search within).

An example, to select Canvec buildings:
* Select 'building=yes' (without quotes), with 'replace selection' checked.
* Select canvec:CODE (with quotes!), with 'find in selection' checked.
This will select buildings imported which have a 'canvec:CODE' attribute.

Note that the current rules.txt file doesn't include a buidling=yes 
attribute for all buildings. When doing the import near Quebec City 
(tile 021L), I added that code manually. All cases I have evaluated are 
indeed buildings. And it wouldn't make sense to put non-buildings in the 
buildings layer. Maybe Sam can comment on this.

Speaking about duplicate nodes: I still need to use the Validator to 
solve them in the Charlevoix area. I imported the forested areas without 
merging them in existing OSM data, because there were no existing 
forests. However, there were already water features adjacent to those 
wooded areas. So, a note to people doing imports: please make sure that 
any validation errors are resolved as much as possible. Not all errors 
can be resolved (like some incorrect tag/value errors), but the 
graphical errors can. And re. warnings and other things found during 
validation: that is almost impossible. Maybe the validation rules of 
JOSM need some finetuning.

Cheers,

Frank

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

Re: [Talk-ca] Administrative boundaries Quebec

[Frank Steggink]

Nicolas Gignac wrote:
 Yeah, I know, but as an overlays it is still showing what it can be 
 integrated into OSM, it is a good start!!!
 What is your strategy to clear legal details?
 If you need help stay in touch with me, because I am working in the 
 government of Quebec and I know really well the people at the 
 Ministère des Ressources Naturelles du Québec.
 I will send them the link of Frank this week and explain to them the 
 possibility it can bring to free some of their data.

 Cheers,

 Nicolas
Hi Nicolas,

There is not really a strategy, only that you can ask them if they agree 
that their data is contributed to OpenStreetMap, under the CC-BY-SA 
license. See [1] and [2] for more details.

Since the use of the Open Database License (ODbL) is under way for quite 
a while now, and a decision should be taken quite soon, it would also be 
good to check if they agree that the ODbL will be applied on their data 
in the future.

It is also strongly recommended to get the eventual agreement in 
writing. That doesn't need to be a paper letter, but can also by e-mail. 
The import will be done under a separate account, so in case any 
problems might arise, this data can be removed without too much trouble.

Since you're working for the government of Quebec, you likely know the 
best which person(s) / department(s) to contact. In case they would like 
to see examples, you can refer to the Geobase / Canvec import. 
Furthermore, [3] lists a lot of examples of imports.

Regards, and thanks in advance for picking this up,

Frank

[1] http://wiki.openstreetmap.org/wiki/License
[2] http://wiki.openstreetmap.org/wiki/Legal_FAQ
[3] http://wiki.openstreetmap.org/wiki/Import/Catalogue


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

[Talk-ca] Import of large features in Canvec

[Frank Steggink]

Hi all,

Today I have (finally) worked on large features in Canvec data (forests, 
water, etc.), and I have come up with a method how to deal with them. 
This currently involves PostGIS, but maybe I'll use GEOS or another 
method, so that it isn't necessary to load data in a DB. More details 
will follow soon, since I need to clean up code / sort out things a bit, 
and eventually integrate it into the canvec_to_osm.py script.

Right now I've uploaded (only) wooded areas in the Charlevoix region in 
Quebec. This already makes the map look entirely different! The result 
can be found here [1]. Changesets: [2] and [3].

You'll see faint horizontal and vertical lines crisscrossing the area. 
This is an artifact of making the features smaller (0.1 x 0.05 degrees). 
This will be dealt with with the gamma option which is part of the new 
Mapnik 0.7.0 release. This will probably be used in a couple of weeks on 
osm.org. See [4] for more info.

Cheers,

Frank

[1] 
http://www.openstreetmap.org/?lat=47.625lon=-70.25zoom=11layers=B000FTFT
[2] http://www.openstreetmap.org/browse/changeset/3707953
[3] http://www.openstreetmap.org/browse/changeset/3708062
[4] http://trac.mapnik.org/wiki/PolygonSymbolizer


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

Re: [Talk-ca] Administrative boundaries Quebec

[Frank Steggink]

Emilie Laffray wrote:
 On 23/01/2010 06:38, Sam Vekemans wrote:
   
 Mapnik -osm2pgsql layers

 Thats awesome visualization!

 Is it possable to create a mapnik osm2pgsql set of layers that would
 allow seeing just select features?

 I guess im talking about a wmf service. (which i barely understand)
 But wont that require separate hosting of the data?  (or rather, a
 rendering of the planet that just has land  sea) where all the other
 features can be added with a osm2pgsql layer?

 (if you dont follow, thats ok)

 All i need to know if its technically possable :) ~ probably just
 requires oodles of computing power for it.

 Cheers,
 Sam
   
 

 You don't necessarily need a WMS server. You can create queries directly
 through postgis and add it to a layer; for example, http://beta.letuffe.org/
 I don't know how it is configured but the person behind it Sylvain
 Letuffe would glad to explain if need be. It was this server that we use
 to overlay the CORINE rendering over the current map. This serveur is
 used to visualize boundaries in France.

 Emilie Laffray
   
Hi Sam, Emilie,

What I did, and what is also done on the site of Sylvain Letuffe, is  
generating transparent images. Instead of specifying a background color 
in the XML config for Mapnik, you can also specify transparent as 
background. Furthermore, it is possible to specify the opacity for 
feature classes, so all sorts of combinations are possible. If you have 
multiple such layers, and use them as overlays, then you get the effect 
that you can toggle layers on and off.

This requires less processing power and is faster than WMS, because 
these tiles can be cached or prerendered, which is not really feasible 
with WMS. (This is unless you use WMS with a tile cache.)

Frank


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

Re: [Talk-ca] Administrative boundaries Quebec

[Frank Steggink]

Lennard wrote:
 Pierre-Luc Beaudoin wrote:

   
 You have strong Mapnik / osm2pgsql skills! :)
 

 The force is strong in this apprentice.

   
Master Ldp,

OK, I needed some guidance. So what?
I'll spare the details; that would only be humiliating. ;)

Frank

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

Re: [Talk-ca] Administrative boundaries Quebec

[Frank Steggink]

Frank Steggink wrote:
 Frank Steggink wrote:
   
 Hi,

 As a bit of a challenge I've looked at the administrative data pointed 
 out by Nicolas Gignac: [1]. I know there are some doubts about the 
 accuracy, but this was also meant as an exercise to deal with this kind 
 of data. Maybe it can be reused for other purposes, although I haven't 
 written the tool I used in a generic way. I also hope that the more 
 accurate (1:20k) data uses the same structure.

 First I converted this data to SHP (with an ESRI tool called Import71, 
 and then ogr2ogr). Then it was converted to OSM with shp-to-osm.jar. 
 However, the data has a topological structure, so it has not much value 
 if it would be imported into OSM directly.

 The set of administrative boundaries contains municipalities, MRCs, 
 administrative regions (17) and urban agglomerates. The municipal data 
 contains also information about MRC, admin. regions and agglomerates, so 
 I decided to examine this further. Now the topological structure was a 
 benefit, because this is how administrative boundaries should also be 
 entered in OSM. The boundaries only contain attributes like from-node, 
 to-node, left-poly and right-poly. However, this is enough to compose 
 relationships (type=multipolygon/boundary, boundary=administrative, 
 etc.) out of them. Because I ended with an ArcInfo coverage as a result 
 of the conversion by Import71, I decided to extract data from the file 
 pat.adf to get the municipality and other relevant names, codes, etc.

 So far I have only created relationships, including the municipality 
 name. I would like to share it with you, in order to gather feedback. 
 The result can be found here: [2]. PLEASE do NOT upload this data to 
 OSM! The ways are sorted in the relationship, so they form closed 
 chains. Also the nodes where multiple ways meet have been deduplicated, 
 otherwise JOSM (and also OSM itself) won't recognize the ways as being 
 connected. The deduplication was based on the actual coordinates, not 
 the node IDs used in the topology.

 Things to do:
 * Detect which boundary is the outer boundary, and which ones are the 
 inner boundaries. Obviously, the ring with the biggest surface area is 
 the outer boundary, and the rest are inner boundaries.
 * Add multiple municipalities in the same relationship.
 * Create MRCs, administrative regions, and urban agglomerates.

 More information about administrative boundaries can be found in [3]. 
 For Canadian provinces admin_level=4 should be used, for regional 
 municipalities (MRCs in Quebec) admin_level=6, and actual municipalities 
 admin_level=8. I would like to propose to use admin_level=5 for the 
 regions. They have at least a semi-offical status. Others might be able 
 to elaborate on it more. This leaves the urban agglomerates (Montreal 
 and Quebec only), for which admin_level=7 would be a natural choice, 
 although I'm not sure if they have any official status. What do you guys 
 think?

 Regards,

 Frank

 [1] 
 http://www.mrnf.gouv.qc.ca/territoire/portrait/portrait-donnees-mille.jsp
 [2] http://www.steggink.org/osm/Quebec/quebec_munic.zip
 [3] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative


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

   
 
 A clarification on this: Add multiple municipalities in the same 
 relationship. Several municipalities have exclaves, like outlying 
 islands. They are divided over multiple polygons, so I created multiple 
 relations for them.

 For the higher-level administrative boundaries, I intend to use 
 information from the AAT file which was generated by Import71. This file 
 contains records describing the boundary type. Although there is 
 specific data for each level, in OSM it would be best to reuse the same 
 set of nodes and ways, and that can best be done by using the same 
 source data.

 Frank


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

   

Hi all,

The last days I've flexed my Mapnik / osm2pgsql skills, and was able to 
put a visualization of the tiles online. They can be found here: [1]. 
The tiles themselves are generated as transparent PNGs, so they didn't 
have to be integrated into the data. Note that I also adjusted the 
zoomlevels, so they are visible earlier than they would be normally. 
Levels 6 - 13 are available, but the last level is still rendering as I 
write this. I haven't take care of any labeling yet, although it is 
present in the DB.

Cheers,

Frank

[1] http://mijndev.openstreetmap.nl/~fsteggink/quebec_admin.html


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

Re: [Talk-ca] Administrative boundaries of Québec

[steggink]

Hi Pierre-Luc,

Thank you for your insights. I was under the impression that the  
Communautés métropolitaines had less authority than MRCs, although I  
didn't look into it. If it weren't for these comets (as this dataset  
is called), there wouldn't be a problem.

However, when looking at the extent of the Communauté métropolitaine  
de Québec ([1]), it turns out that it spans multiple regions  
(Capitale-Nationale and Chaudière-Appalaches), so it doesn't fit  
nicely in the hierarchy. I think it would be better to treat them as a  
different entity, and admin_level=6 can be used for the MRCs. The  
Montreal comet contains municipalities of even more regions  
(Montreal, Laval, Montérégie, Laurentides, Lanaudière).

Regarding MRCs vs urban areas: I'll check in the data if that  
information can be disseminated. Because they and MRCs are mutually  
exclusive, they can have the same admin_level, but their designations  
should properly reflect the situation. Wikipedia has an overview of  
the agglomerations: [2]. I wonder if this list is really complete, and  
I don't think that all of them are MRC equivalents. In Quebec City  
there are also the enclaves of Wendake (First Nations) and  
Notre-Dame-des-Anges (covering only the Hôpital général de Québec).  
Anyways, I'll use the information from the geodata, and not base  
anything on Wikipedia.

The borough map of Quebec is already outdated. Things got change on  
Nov 1st last year. La Cité and Limoilou have merged, and Laurentides  
has been divided over other boroughs. See [3]. Anyways, a minor detail  
:)

For the other types of boundaries (electorial districts,  
schoolboards), other values for the boundary keys should be used. [4]  
For electorial boundaries boundary=political is used  
(boundary=electorial would be better imho).

Regards,

Frank

[1]  
http://en.wikipedia.org/wiki/Communaut%C3%A9_m%C3%A9tropolitaine_de_Qu%C3%A9bec
[2] http://en.wikipedia.org/wiki/Urban_agglomerations_of_Quebec
[3]  
http://www.ville.quebec.qc.ca/temp/modifications_arrondissements/index.aspx
[4] http://wiki.openstreetmap.org/wiki/Key:boundary

Quoting Pierre-Luc Beaudoin pierre-...@pierlux.com:

 Hi,

 Let's start a thread to create an official organization of the
 administrative divisions in regards with the numbering in OSM [1].

 Skipping levels higher than 4 (reserved for things greater than Québec).

 Here's my first shot based on all the info I could find on the Ministère
 des affaires minicipales, des régions de l'Occupation du territoire
 (gosh they like the long names!) [3]:

 Level 4: Provinces and territories
 Level 5: Région administratives / Administrative regions
 (Level 5.5: Here would fit L'Agence métropolitaine de transport, not  
  worth mapping)
 Level 6: Communautés métropolitaines / Urbans or metropolitan communities
 Level 7: Municipalités régionales de compté (MRCs)
 (Level 7.5: Here would fit the Conférences régionales des élus of   
 Montérégie (which is divided in 3), other CRÉ match their MRC   
 boundaries, but I believe this information is not worth of mapping.   
  Maps [4]).
 Level 8: Municipalités et villes / Municipalities, Cities
 Level 9: Arrondissements / Boroughs
 Level 10: Quartier / Quarter

 This list does not contain federal electoral districts, provincial
 electoral districts, municipal electoral districts, school boards,
 Régions municipales de recensement and Agglomérations de
 recensement [5] (what are theses?). Should we include all of them?

 Now if you look closely at the wiki table, my suggestion doesn't fit
 with the rest of Canada: Québec's MRCs would be one level down compared
 to Ontario.  That's because we have 2 levels between the province and
 the cities.

 A real life example would be for the place I used to live in Québec
 City:

 Level 4: Québec
 Level 5: Capitale-Nationale (ref=03)
 Level 6: Communauté urbaine de Québec
 Level 7 is N/A (Québec is not part of an MRC, being a big city)
 Level 8: Québec
 Level 9: La cité (Map of the borough [2])
 Level 10: Montcalm

 I believe it would make sens for all those names show up on a map as
 they are commonly used.

 Are there other opinions?

 Pierre-Luc

 NB: I believe there was a report from the OCDE stating that Montréal was
 being over administrated.  I agree :)

 [1]: http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative
 [2]:
 http://www.ville.quebec.qc.ca/apropos/portrait/arrondissements/lacite/plan.aspx
 [3] http://www.mamrot.gouv.qc.ca
 [4] http://www.mamrot.gouv.qc.ca/publications/cartotheque/CRE.pdf
 [5]
 http://www.mamrot.gouv.qc.ca/publications/cartotheque/atlas_AR_RMR.pdf





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

[Talk-ca] Administrative boundaries Quebec

[Frank Steggink]

Hi,

As a bit of a challenge I've looked at the administrative data pointed 
out by Nicolas Gignac: [1]. I know there are some doubts about the 
accuracy, but this was also meant as an exercise to deal with this kind 
of data. Maybe it can be reused for other purposes, although I haven't 
written the tool I used in a generic way. I also hope that the more 
accurate (1:20k) data uses the same structure.

First I converted this data to SHP (with an ESRI tool called Import71, 
and then ogr2ogr). Then it was converted to OSM with shp-to-osm.jar. 
However, the data has a topological structure, so it has not much value 
if it would be imported into OSM directly.

The set of administrative boundaries contains municipalities, MRCs, 
administrative regions (17) and urban agglomerates. The municipal data 
contains also information about MRC, admin. regions and agglomerates, so 
I decided to examine this further. Now the topological structure was a 
benefit, because this is how administrative boundaries should also be 
entered in OSM. The boundaries only contain attributes like from-node, 
to-node, left-poly and right-poly. However, this is enough to compose 
relationships (type=multipolygon/boundary, boundary=administrative, 
etc.) out of them. Because I ended with an ArcInfo coverage as a result 
of the conversion by Import71, I decided to extract data from the file 
pat.adf to get the municipality and other relevant names, codes, etc.

So far I have only created relationships, including the municipality 
name. I would like to share it with you, in order to gather feedback. 
The result can be found here: [2]. PLEASE do NOT upload this data to 
OSM! The ways are sorted in the relationship, so they form closed 
chains. Also the nodes where multiple ways meet have been deduplicated, 
otherwise JOSM (and also OSM itself) won't recognize the ways as being 
connected. The deduplication was based on the actual coordinates, not 
the node IDs used in the topology.

Things to do:
* Detect which boundary is the outer boundary, and which ones are the 
inner boundaries. Obviously, the ring with the biggest surface area is 
the outer boundary, and the rest are inner boundaries.
* Add multiple municipalities in the same relationship.
* Create MRCs, administrative regions, and urban agglomerates.

More information about administrative boundaries can be found in [3]. 
For Canadian provinces admin_level=4 should be used, for regional 
municipalities (MRCs in Quebec) admin_level=6, and actual municipalities 
admin_level=8. I would like to propose to use admin_level=5 for the 
regions. They have at least a semi-offical status. Others might be able 
to elaborate on it more. This leaves the urban agglomerates (Montreal 
and Quebec only), for which admin_level=7 would be a natural choice, 
although I'm not sure if they have any official status. What do you guys 
think?

Regards,

Frank

[1] 
http://www.mrnf.gouv.qc.ca/territoire/portrait/portrait-donnees-mille.jsp
[2] http://www.steggink.org/osm/Quebec/quebec_munic.zip
[3] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative


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

Re: [Talk-ca] Administrative boundaries Quebec

[Frank Steggink]

Frank Steggink wrote:
 Hi,

 As a bit of a challenge I've looked at the administrative data pointed 
 out by Nicolas Gignac: [1]. I know there are some doubts about the 
 accuracy, but this was also meant as an exercise to deal with this kind 
 of data. Maybe it can be reused for other purposes, although I haven't 
 written the tool I used in a generic way. I also hope that the more 
 accurate (1:20k) data uses the same structure.

 First I converted this data to SHP (with an ESRI tool called Import71, 
 and then ogr2ogr). Then it was converted to OSM with shp-to-osm.jar. 
 However, the data has a topological structure, so it has not much value 
 if it would be imported into OSM directly.

 The set of administrative boundaries contains municipalities, MRCs, 
 administrative regions (17) and urban agglomerates. The municipal data 
 contains also information about MRC, admin. regions and agglomerates, so 
 I decided to examine this further. Now the topological structure was a 
 benefit, because this is how administrative boundaries should also be 
 entered in OSM. The boundaries only contain attributes like from-node, 
 to-node, left-poly and right-poly. However, this is enough to compose 
 relationships (type=multipolygon/boundary, boundary=administrative, 
 etc.) out of them. Because I ended with an ArcInfo coverage as a result 
 of the conversion by Import71, I decided to extract data from the file 
 pat.adf to get the municipality and other relevant names, codes, etc.

 So far I have only created relationships, including the municipality 
 name. I would like to share it with you, in order to gather feedback. 
 The result can be found here: [2]. PLEASE do NOT upload this data to 
 OSM! The ways are sorted in the relationship, so they form closed 
 chains. Also the nodes where multiple ways meet have been deduplicated, 
 otherwise JOSM (and also OSM itself) won't recognize the ways as being 
 connected. The deduplication was based on the actual coordinates, not 
 the node IDs used in the topology.

 Things to do:
 * Detect which boundary is the outer boundary, and which ones are the 
 inner boundaries. Obviously, the ring with the biggest surface area is 
 the outer boundary, and the rest are inner boundaries.
 * Add multiple municipalities in the same relationship.
 * Create MRCs, administrative regions, and urban agglomerates.

 More information about administrative boundaries can be found in [3]. 
 For Canadian provinces admin_level=4 should be used, for regional 
 municipalities (MRCs in Quebec) admin_level=6, and actual municipalities 
 admin_level=8. I would like to propose to use admin_level=5 for the 
 regions. They have at least a semi-offical status. Others might be able 
 to elaborate on it more. This leaves the urban agglomerates (Montreal 
 and Quebec only), for which admin_level=7 would be a natural choice, 
 although I'm not sure if they have any official status. What do you guys 
 think?

 Regards,

 Frank

 [1] 
 http://www.mrnf.gouv.qc.ca/territoire/portrait/portrait-donnees-mille.jsp
 [2] http://www.steggink.org/osm/Quebec/quebec_munic.zip
 [3] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative


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

   
A clarification on this: Add multiple municipalities in the same 
relationship. Several municipalities have exclaves, like outlying 
islands. They are divided over multiple polygons, so I created multiple 
relations for them.

For the higher-level administrative boundaries, I intend to use 
information from the AAT file which was generated by Import71. This file 
contains records describing the boundary type. Although there is 
specific data for each level, in OSM it would be best to reuse the same 
set of nodes and ways, and that can best be done by using the same 
source data.

Frank


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

Re: [Talk-ca] Import mess in southern Québec

[Frank Steggink]

Hi Yves,

FWIW, I was able to browse the site, in order to see what is available 
and at what cost, with Ubuntu / Firefox. Maybe you have some extensions 
(like NoScript) blocking something. For one, I had to allow JS to be 
executed, but that's all.

Regarding the infrastructure, there are already several instances where 
it is provided by the OSM community. The current efforts to map Haiti 
are located outside of OSM (on a site from Schuyler Erle), but there are 
also several sites serving data for different purposes within OSM. A 
good example are the Dutch sites (like tiles.openstreetmap.nl, 
mijndev.openstreetmap.nl, etc.), and a site like 
http://ooc.openstreetmap.org/ offering tiles of out-of-copyright data 
covering England and Wales.

It has already been mentioned several times, but it would be the best if 
we would be able to set something up ourselves. This would also be very 
beneficial for the Canvec/Geobase and other imports taking place. But 
then the question arises: who can provide a server, and who can 
administer it? (Unfortunately my experience is limited to administrating 
my own PCs, but a more professional web server is beyond my league.) 
This goes beyond offering storage space, although that remains valuable. 
For on, I would love to put my TopOSM version of Canada there, which I 
showed in Sherbrooke last month. On such a site we could show how 
certain data will look like when imported, for example the 
administrative boundaries Nicolas pointed out.

Frank

Yves Moisan wrote:
 The Geoboutique site also has lots of other interesting data, like 
 orthophotos. Too bad they're expensive. $65 per file, and there are 
 thousands of them. However, we wouldn't need that data per se, but if 
 it would only be available to OSM for tracing purposes (like Yahoo), 
 that would already be very much appreciated :)
 

 Good point !  I don't know how Yahoo can provide the data to OSM for
 free for tracing purposes and in other circumstances sell it to private
 customers.  The Québec air photo data may be a different beast inasmuch
 as IIRC there is one single private provider.  

 One thing I would try to find out is how much money the government of
 Québec (Geoboutique is the government) makes out of selling the air
 photo coverage it paid for.  The logic is pretty basic here : the
 government wants to recoup costs.  I'll put my toe in water and put
 forth this hypothesis : Geoboutique doesn't make a whole lot of money
 selling air photos.  There.  Please prove me wrong.  If they don't get
 much money from sales (and please let's factor in the cost of the
 computing infrastructure needed to sell the data), then there may be
 open ears for sharing data for community purposes.

 The other thing is I'm not sure there is a strong will from the
 government to set up an infrastructure to share it's geodata.  If there
 is to be a special agreement between OSM and the government for tracing
 purposes, there will be a need for such an infrastructure.  

 I just dropped by Geoboutique and I can't get much out of their website
 on my Ubuntu laptop : Ce site est optimisé pour le fureteur Internet
 Explorer version 6..  In fact I complained two years ago that
 Geoboutique (or some other geodata government site) *required* not only
 IE, but Microsoft's JVM for it to work properly.  A year later Firefox
 users were simply told to use IETab to view the site ...  The site says
 not it is optimized for IE6.  Point is : the logic here is
 proprietary, cost-recouping and IE oriented infrastructure.  And it'll
 probably be like that for as long as politicians want even though data
 sales are probably nowhere near what they'd need to be to recover costs.

 Prove me wrong ;-).

 Yves

   
 Frank
 



   


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

Re: [Talk-ca] Import mess in southern Québec

[Frank Steggink]

Hi,

Regarding government contacts: I believe Nicolas has contacts within the 
government himself, so he might be in the best position to make some 
inquiries. It would be wonderful if we could do something really useful 
with it (i.e. importing in OSM).

I've looked at the 1:1M data, and it is in E00 format. With some tools 
(Import71 from ESRI and ogr2ogr) I was able to convert it to SHP, and 
then I used shp-to-osm.jar to convert it to OSM files. So far I haven't 
used any rules files, so I got the bare geometry. Maybe I haven't done 
right in this quick test, but the OSM files don't contain areas, but 
lines. Actually this is perfect for administrative boundaries. Any 
administrative areas should be built up by relationships anyways.

Regarding the accuracy, it was much better than I would expect because 
of the scale. If there would be no alternative, this would certainly be 
acceptable IMHO.

One thing though: I couldn't find any names of the areas. The generated 
DBF files only contain numeric identifiers. During the conversion to SHP 
(through ArcInfo coverages) I got an error from ogr2ogr that it wasn't 
able to convert integer lists to SHP. I don't know the data, so I also 
don't know what data has been dropped. Maybe the identifiers of the area 
to the left and right sides of each way...

The Geoboutique site also has lots of other interesting data, like 
orthophotos. Too bad they're expensive. $65 per file, and there are 
thousands of them. However, we wouldn't need that data per se, but if 
it would only be available to OSM for tracing purposes (like Yahoo), 
that would already be very much appreciated :)

Frank

Sam Vekemans wrote:
 So Quebec (province) has not opened up their dataset yet?
 Good to know.
 Maybe after the NRCan data all gets imported, they might change their mind :)

 Does anyone have contact with the GIS department directly?

 Sam

 On 1/15/10, Pierre-Luc Beaudoin pierre-...@pierlux.com wrote:
   
 On Fri, 2010-01-15 at 22:18 -0500, Pierre-Luc Beaudoin wrote:
 
 We should get in touch with them so we can exchange datasets such as
 Municipalités régionales de comté, City boundaries, counties and
 administrative regions (at least).
   
 They do have the data (1/20 000) in vector format available for sale for
 100$ + conversion rates of 7$ on http://geoboutique.mrnf.gouv.qc.ca .
 Past that, it's only a question of licences.

 Pierre-Luc

 


   


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

Re: [Talk-ca] Import mess in southern Québec

[Frank Steggink]

Regarding the area names: they are in the E00 files, and also in the 
generated pat.adf files, so it shouldn't be a problem to match them up 
with the numeric identifiers.

Frank

Frank Steggink wrote:
 Hi,

 Regarding government contacts: I believe Nicolas has contacts within the 
 government himself, so he might be in the best position to make some 
 inquiries. It would be wonderful if we could do something really useful 
 with it (i.e. importing in OSM).

 I've looked at the 1:1M data, and it is in E00 format. With some tools 
 (Import71 from ESRI and ogr2ogr) I was able to convert it to SHP, and 
 then I used shp-to-osm.jar to convert it to OSM files. So far I haven't 
 used any rules files, so I got the bare geometry. Maybe I haven't done 
 right in this quick test, but the OSM files don't contain areas, but 
 lines. Actually this is perfect for administrative boundaries. Any 
 administrative areas should be built up by relationships anyways.

 Regarding the accuracy, it was much better than I would expect because 
 of the scale. If there would be no alternative, this would certainly be 
 acceptable IMHO.

 One thing though: I couldn't find any names of the areas. The generated 
 DBF files only contain numeric identifiers. During the conversion to SHP 
 (through ArcInfo coverages) I got an error from ogr2ogr that it wasn't 
 able to convert integer lists to SHP. I don't know the data, so I also 
 don't know what data has been dropped. Maybe the identifiers of the area 
 to the left and right sides of each way...

 The Geoboutique site also has lots of other interesting data, like 
 orthophotos. Too bad they're expensive. $65 per file, and there are 
 thousands of them. However, we wouldn't need that data per se, but if 
 it would only be available to OSM for tracing purposes (like Yahoo), 
 that would already be very much appreciated :)

 Frank

 Sam Vekemans wrote:
   
 So Quebec (province) has not opened up their dataset yet?
 Good to know.
 Maybe after the NRCan data all gets imported, they might change their mind :)

 Does anyone have contact with the GIS department directly?

 Sam

 On 1/15/10, Pierre-Luc Beaudoin pierre-...@pierlux.com wrote:
   
 
 On Fri, 2010-01-15 at 22:18 -0500, Pierre-Luc Beaudoin wrote:
 
   
 We should get in touch with them so we can exchange datasets such as
 Municipalités régionales de comté, City boundaries, counties and
 administrative regions (at least).
   
 
 They do have the data (1/20 000) in vector format available for sale for
 100$ + conversion rates of 7$ on http://geoboutique.mrnf.gouv.qc.ca .
 Past that, it's only a question of licences.

 Pierre-Luc

 
   
   
 


 ___
 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] FW: Canvec import in Montréal with ? names

[Frank Steggink]

Hi,

I'll create a number of OSM files based on Geobase which can be imported 
by Daniel. Re. the existing data, it might be better to remove it, 
although I don't know how much it is. Daniel, are your imports only 
confined to Laval, or do they extend other tiles? I can create a script 
which can undo your changes. I've created something similar to clean up 
the mess after a few early botched Geobase imports of myself.

Do we all agree to remove this data, and import Geobase instead? This 
conversion process has proven the test of time now. I can make a number 
of NTS tiles with Geobase data available.

As Sam mentioned, it was indeed the intention to use Geobase for the 
road import. The tags which are set on Canvec data (by shp2osm.jar / 
canvec2osm.py) are mostly OK, except for roads. I should have said that 
when I asked you why you used Canvec, instead of Geobase. Technically 
the source data is the same, but not the result as converted to OSM ;)

Cheers,

Frank

Daniel Bégin wrote:

 Hi all, I'm guilty!

  

 Actually, I'm importing the Canvec road network in Laval (north of 
 Montreal) because I've done a lot GPS mapping in this area.  Last week 
 I used canvec-to-osm to convert the rest of the road network.  So, if 
 the tags are not appropriate, something should be modified in the 
 application. 

  

 Curiously, I used the same application few weeks ago near Sherbrooke 
 area and did not have that problem?!!  Someone can explain it to me?

  

 However, I am in the process of correcting the data I imported. It has 
 not only odd tags but a problem using JOSM creates a lot of duplicate 
 ways.

  

 Which tags do you suggest I keep/remove? Pierre-Luc suggested me to 
 remove tags with ? values, any other suggestions? I can easily 
 removed odd tags at the same time I'm correcting my ways.

  

 Cheers,

  

 Daniel

  

 -Original Message-

 From: talk-ca-boun...@openstreetmap.org 
 [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Pierre-Luc 
 Beaudoin

 Sent: December 10, 2009 23:18

 To: Talk-CA OpenStreetMap

 Subject: [Talk-ca] Canvec import in Montréal with ? names

  

 Hi,

  

 I've been a little disconnected about the whole import process. Tonight

 I've seen CanVec streets appear in my neighboorhood with odd tags such

 as:

  

 http://www.openstreetmap.org/?lat=45.509963468565353lon=-73.561728000640869zoom=18

 name = ?

 name2= ?

 address:street:leftside=?

 address:street:rightside=?

 is_in=?

  

 I believe such approach is unproductive as it takes quite a lot of work

 to clean up the tags afterwards or even to print a nice map without ?

 everywhere.

  

 Tags should not be set to FIXME or ?.  They should not be set. Then

 they'll show up on the no name layer. Please someone fix that import

 script. :)

  

 Pierre-Luc

  

  

  

 

 ___
 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] FW: Canvec import in Montréal with ? names

[Frank Steggink]

On second thought: obviously a lot of work has gone in it, and many tags 
are already set. I haven't looked at it, but probably the roads are also 
being linked up with the existing grid. There might be some 
inconsistencies with Geobase, but I don't think that will really be a 
problem. Actually, Daniel is our in-house expert on this matter, so he 
should be able to tell :)

JOSM has some good tools to select features, and edit their tags. With 
this it shouldn't be too hard to unset all tags with question marks. 
There is also a number of duplicate roads, which can be located with the 
Validator tool, as well as some roads of which the classification needs 
to change. On Hwy 13 some green (trunk) sections stand out. Bridges? 
I'll have a look at this.

Along many motorways there are unclassified roads. Normally I would 
change them to motorway_link, but in Montreal most of them are secondary 
or tertiary. I think this depends on whether there are buildings along 
it, correct? Perhaps this is best to be fixed by someone familiar with 
this area. I could also change it, and someone else can update my 
corrections.

Frank

Frank Steggink wrote:
 Hi,

 I'll create a number of OSM files based on Geobase which can be 
 imported by Daniel. Re. the existing data, it might be better to 
 remove it, although I don't know how much it is. Daniel, are your 
 imports only confined to Laval, or do they extend other tiles? I can 
 create a script which can undo your changes. I've created something 
 similar to clean up the mess after a few early botched Geobase imports 
 of myself.

 Do we all agree to remove this data, and import Geobase instead? This 
 conversion process has proven the test of time now. I can make a 
 number of NTS tiles with Geobase data available.

 As Sam mentioned, it was indeed the intention to use Geobase for the 
 road import. The tags which are set on Canvec data (by shp2osm.jar / 
 canvec2osm.py) are mostly OK, except for roads. I should have said 
 that when I asked you why you used Canvec, instead of Geobase. 
 Technically the source data is the same, but not the result as 
 converted to OSM ;)

 Cheers,

 Frank

 Daniel Bégin wrote:

 Hi all, I'm guilty!

  

 Actually, I'm importing the Canvec road network in Laval (north of 
 Montreal) because I've done a lot GPS mapping in this area.  Last 
 week I used canvec-to-osm to convert the rest of the road network.  
 So, if the tags are not appropriate, something should be modified in 
 the application.
  

 Curiously, I used the same application few weeks ago near Sherbrooke 
 area and did not have that problem?!!  Someone can explain it to me?

  

 However, I am in the process of correcting the data I imported. It 
 has not only odd tags but a problem using JOSM creates a lot of 
 duplicate ways.

  

 Which tags do you suggest I keep/remove? Pierre-Luc suggested me to 
 remove tags with ? values, any other suggestions? I can easily 
 removed odd tags at the same time I'm correcting my ways.

  

 Cheers,

  

 Daniel

  

 -Original Message-

 From: talk-ca-boun...@openstreetmap.org 
 [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Pierre-Luc 
 Beaudoin

 Sent: December 10, 2009 23:18

 To: Talk-CA OpenStreetMap

 Subject: [Talk-ca] Canvec import in Montréal with ? names

  

 Hi,

  

 I've been a little disconnected about the whole import process. Tonight

 I've seen CanVec streets appear in my neighboorhood with odd tags such

 as:

  

 http://www.openstreetmap.org/?lat=45.509963468565353lon=-73.561728000640869zoom=18
  


 name = ?

 name2= ?

 address:street:leftside=?

 address:street:rightside=?

 is_in=?

  

 I believe such approach is unproductive as it takes quite a lot of work

 to clean up the tags afterwards or even to print a nice map without ?

 everywhere.

  

 Tags should not be set to FIXME or ?.  They should not be set. Then

 they'll show up on the no name layer. Please someone fix that import

 script. :)

  

 Pierre-Luc

  

  

  

 

 ___
 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] FW: Canvec import in Montréal with ? names

[Frank Steggink]

Hi Daniel,

 The problem is confined in and around Laval area. It won't be necessary to
 remove the roads because there is already a lot of work that have been done
 and I am completing the correction - using JOSM.  If the community give me
 enough time ;-) 

 It will be all set properly soon :-)
   
OK, I'll leave it to you then. You imported this data after all ;) You 
have noticed the Search button in the Selection pane, right?
 By the way, why using only Geobase while Canvec is identical.  I have the
 impression the initial decision was based on the impression Geobase was
 better. Am I right?
   
Others can better answer the question about the impression than I do. If 
you want to use Canvec, we should make sure that equivalent tags are 
present too. It would be more difficult to add missing information later.

Good luck,

Frank


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

Re: [Talk-ca] OSM

[Frank Steggink]

Alan Philip wrote:
 Hello, Frank:

 My name is Alan Philip. I am a retired cartographer currently living in
 Duncan, BC. Sam Vekemans has forwarded to you an email from another OSM
 mapper (Dr. Brian Grady) who has been in touch with me about trail maps
 I have made in the Victoria area when I lived there. I have those trails
 in a GIS and am willing to make them available to the public.

 I am wondering, first of all, what classification system OSM uses for
 trails, so that I can match it. Secondly, what is the process for
 getting data into OSM? I have joined OSM but have not been able to get
 down to any meetings in Victoria.

 I have a friend who has also done a lot of trail mapping west of
 Victoria who would probably be interested in this.

 Most of my mapping was done by compass and pacing, with the occasional
 GPS tie in openings, so I do not have GPS traces. I just bought a better
 GPS so I am now doing trail mapping using that in the Duncan area.

 Cheers,
 Alan Philip
   

Hello Alan,

Thank you for showing your interest in OpenStreetMap. First of all I 
would like to express that there is actually not a single person in 
charge responsible for organizing all data in Canada. OSM is a community 
effort, so it would have been more appropriate if you were redirected to 
the talk-ca list. Many people are following this list, all with their 
own unique skills and interests, but with a common goal of making OSM a 
freely accessible repository of geospatial data. In case you haven't 
already subscribed to the talk-ca list, it can be done here: [1].

Anyways, here are some answers for your questions. The core 
classification system can be found on the Map Features page in the wiki: 
[2]. This classification system is not fixed, so if a particular feature 
type isn't well represented, it is possible to add your own tags. This 
is a rather large difference from classical GIS systems, which have 
strict feature definitions with a fixed set of properties. However, over 
time consensus grows for many different feature types, and those are 
listed on the Map Features page. A single tag consists of a key with a 
value.

As you see, there are multiple options. One possible option is 
highway=track. These are predominantly used for roads for agricultural 
or forestry usage. It is possible to tell something about the track 
quality with the tracktype tag. Another option is highway=footway. This 
tag is more intended to be used an urban environment, like parks, 
footpaths, etc. Furthermore there is highway=path which is more intended 
in a rural setting. The precise details can be found on the MapFeatures 
page. If a name is available, the 'name' tag can be used. There are also 
several tags available if the trails are a part of certain routes, or 
they have special designations (like a trail number). Eventually a 
relation can be used, which is a method to combine nodes and ways, for 
example to form a route.

Regarding your second question: if the data is already available in a 
popular GIS format, then it is possible to convert this to an OSM file. 
This is the internal data format of OSM Such a file can be opened by 
JOSM [3], which is an OSM editor. If there are attributes alongside it 
(like the name, etc.), they can be made available too. In what GIS 
format is the data actually stored? If it is not in a popular GIS 
format, it might be necessary that the data is converted first to one of 
the more popular formats like SHP, and after that the data can be 
converted to OSM format. Once this has happened, and the proper tags 
have been set, this data can be uploaded with JOSM. Can I ask how much 
data you have? And is it possible make a sample available?

Finally I would like to remind you that the copyright of the data is an 
important issue. If maps, aerials or other data sources have been 
involved in creating this data, which has a license which is 
incompatible with OSM (currently CC-BY-SA), then I'm afraid that it 
can't be used. Judging from your description (the data is all coming 
from you), this likely isn't the case. Since NRCan has given us 
permission to load their data into OSM (the Geobase / Canvec import 
processes), it is no problem if their maps have been used.

About meetings in Victoria and surroundings: I'm not well familiar with 
those, since I'm living in Quebec myself. There are several mappers from 
Vancouver Island subscribed to this list. They can get in touch with you 
in order to attend any local meetings. Several of them have listed 
themselves on the wiki: [4]. There is even a separate city page for 
Duncan: [5], listing another local mapper.

Cheers,

Frank Steggink

[1] http://lists.openstreetmap.org/listinfo/talk-ca
[2] http://wiki.openstreetmap.org/index.php/Map_features
[3] http://wiki.openstreetmap.org/wiki/JOSM
[4] http://wiki.openstreetmap.org/wiki/Canada:British_Columbia
[5] http://wiki.openstreetmap.org/wiki/Canada:British_Columbia:Duncan

Re: [Talk-ca] [Imports] Canvec import

[Frank Steggink]

Hi Sam,

I'll try to keep it short, and I won't crosspost to Imports and OSM dev 
Sherbrooke. Only the original message was posted to those lists as well, 
since there have been Canvec-related discussions on them in the past.

 What was not mentioned is that CanVec is just 1 of the many datasets
 that are available.
   
The focus of the meeting, and of my previous e-mail was predominantly on 
Canvec. Trying to do everything at once, means that in the end nothing 
at all is done. I know that there is more data out there.
 Do you want to set up a 'post process' national database as a
 repository of data?
 Then a web interface to handle it all? (perform the on-demand internal
 conversion)
   
What I want is something that works for all of us. Obviously I can't, 
and won't decide that on my own. Anyways, something similar in nature as 
what Emilie showed, is the way to go. We all concluded that. I haven't 
had the occasion to have an in-depth look at it, but from what I 
understood a user could select a particular area. He could convert the 
data to OSM. During this the data is split into 3 categories, depending 
on overlap with existing OSM data. Data without any overlap was imported 
automatically (although triggered by human action), and the rest was 
imported manually. The conversion was already done, and the changes 
made available somehow.
 Before,  i did recommended that internationally, we have a
 'post-OSM-importable-data' database'. but my voice wasnt understood
   
What do you mean by that? The file repository on Mediafire you created? 
And in particular, the resulting files after OpenJump / Roadmatcher has 
been applied to Geobase input data, which were later converted to OSM 
files? Or possibly also the files of the simplified process, in which 
data is copied over manually?

To be fair, I kinda liked the latter process. My experience with 
OpenJump / Roadmatcher wasn't that it was worth the effort (due to 
ending up adding / removing many nodes, and retiring ways myself), 
compared to the simplified process. However, there is no way to revisit 
the data, even not if you make the files available. It is very easy to 
forget roads during the import, so you end up adding scattered roads later.
 (because i can see the project on an overall scale, and most people,
 just focus on their local area) :-) ...oh well, like frank said, i
 suck at communicating. :)
   
Thank you very much for rephrasing my words, I do appreciate that. 
Anyways, you just came to the conclusion that your voice wasn't 
understood. This has everything to do with your communication style, and 
you know that. Anyways, there is no point in debating this further, and 
if you still think you should, please keep it off the list.
 Its similar in concept to OpenAerialMap)
   
What role does OpenAerialMap suddenly play here? It is as if a number of 
steps in your thought process are skipped, so I got lost.
 This way, it becomes a true 'community effort' for actually getting
 the data from the web-interface to OSM.

 The technical part of the back-end database 'warehouse', maybe thats
 something we can check with the OSGeo Community, as that is what they
 are working on. (where the imports@ list becomes a point of contact
 with the OSGeo community,
Sure. We should reuse as much as possible, otherwise it will be too much 
work. Many people have developed excellent, useful tools. The Imports, 
and also the Dev list will be involved when necessary, but they don't 
need to follow each single step we're making.
By the way, the Imports list is an OSM list, and does not have direct 
contact with OSGeo, which is a different entity: [1]
  since that database will not be 'tainted' or
 'improved' (depending on your POV)
   
You lost me again.

Regards,

Frank

[1] http://www.osgeo.org/


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

Re: [Talk-ca] CanVec import chat @Sherbrook

[Frank Steggink]

Sam Vekemans wrote:
 Hi Frank,
  I get the feeling that the group doesnt want me to be working with
 the import process anymore (since i wasnt invited to the chat after
 Emelie was done speaking)
 is that a fair assumption?

 Anyway, thats (seriously) fine for me, as its a BIG wait off my shoulders.

 So anyway, im very happy that your doing a great job with the CanVec
 data import.

 Its a long process, and i do recognize that my approach is different that 
 yours.

 I'll forward questions people have to the talk-ca list  you directly.

 Overall, i think that since your directly in contact with Daniel  the
 others, i would (probably) just get in the way. :-)

 So anyway, i'll continue to be the one who is 'keeping a national eye'
 on the progress, but as far as the technical details, its yourself
 thats in charge of that, method etc.

 Since i am working as a local area mapper for more parts of the
 country than most, i'll be aware of the progress, and so, i can be a
 point of contact for newbies and direct them to the talk-ca list. (and
 use whatever process that will be decided)

 I'll continue to be working on my next projects 'Across Canada Trails'
 and 'WikiMAP Books Publishing'.

 Thanks for doing an AWESOME job so far,

 Cheers,
 Sam Vekemans
 Across Canada Trails  WikiMAP Books
   
Hi Sam,

I have sent you a private e-mail, because I don't think it would be 
appropriate to send it to both lists, and that it would end up in the 
OSM talk archives.

Frank



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

Re: [Talk-ca] buildings to OSM

[Frank Steggink]

Hi M.A. Gagnon,

The goal is to import nearly all of the features of Canvec. That is why 
the conversion script is converting all the themes at once, but not per 
theme.  However, I can imagine that it is more convenient to focus on 
one or a few themes at first. This would be a nice addition for the next 
version of canvec_to_osm. So far the only thing I considered adding was 
support to download 256 NTS tiles at once. I'm not sure when I'll be 
working on it, but once it is done, I'll post it on talk-ca.

The first thing I did when taking over the maintenance of this script 
was converting it to Python. Many people, including me, aren't running 
Windows. And of course Python is a much more flexible scripting language 
than .bat files. You can find Python at http://www.python.org. The 
script itself can be found at [1]. This download does not contain Ian 
Dees' JAR file, because it can be downloaded from his site. In case 
you're not familiar with Python (and if you use Windows): 1) make sure 
python.exe is available in your PATH variable; 2) the script is executed 
by typing python canvec-to-osm.py [options] in a command prompt.

In the meantime I've put the sources and the rules files on [2], so that 
eventual interested people can work on it as well. I renamed the .py 
files, because using hyphens in the name is a bit awkward, but I didn't 
make any other changes.

If you have questions or comments, please let me know.

Regards,

Frank

[1] http://www.steggink.org/osm/Canvec/Canvec-to-osm_v0.1.zip
[2] 
http://svn.openstreetmap.org/applications/utils/import/canvec_import/canvec_to_osm/


Sam Vekemans wrote:
 Hi,
 At 6pm PST i'll be broadcasting live on tinychat.com/acrosscanada and
 ustream.tv/channel/acrosscanadatra and on my facebook profile  live
 on twitter, as well as available on skype for video call in.

 Mainly about the full Canada Import status, as there is ALOT going on,
 and important to know too. I'll save a recording on youtube.

 And ya, i'll answer your questions too :)

 ps. The talk-ca list is our main communication device for Canada,
 you'll need to subscribe to get messages through.
 -so we all know whats up :)

 cheers,
 Sam


 On 12/2/09, mag.gag...@gmail.com mag.gag...@gmail.com wrote:
   
 Thanks for the reply. BTW, I'm senior Analyst at CRTC responsible for all
 kinds of telecom and broadcasting GIS data. Let me know if you ever need
 anything telcom related.
 My answers below.

 
 Are you refering to building nodes or areas?
   
 All buildings eg: _BS_ files. A mix of points, lines, areas

 
 What area/tiles are you working on?
   
 Got the complete package from off the web, unziped and trying to pack as
 one object.


 
 Were actually working on converting all the canvec data at once.
   
 Cool. Will follow this very closely.


 
 Frank is now the main person who is working on the script.
   
 Dont know this frank

 
 What is it that your having problems with? Whats the error message say?
   
 Was hoping to have file for combining only buildings eg: all _BS_
 together.

 


   


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

Re: [Talk-ca] Help for Canvec to OSM for part of NB

[Frank Steggink]

Hi John,

I must admit that I hardly know anything about setuptools and Python 
eggs. It seems that easy_install (part of setuptools) automatically 
downloads and installs missing dependencies. So, when you install the 
GDAL bindings, it should also install GDAL (of which OGR is a part) for you.

Setuptools can be found here: http://pypi.python.org/pypi/setuptools
Here is an introduction about Python eggs: 
http://mrtopf.de/blog/python_zope/a-small-introduction-to-python-eggs/ . 
A large part deals with creating eggs, so you can skip that.

Good luck,

Frank


JOHN SMART wrote:
 Hi Frank

 Yes I'm on Windows. Where I am today:
 - installed GDAL 1.6.1 from
 http://pypi.python.org/packages/2.6/G/GDAL/GDAL-1.6.1.win32-py2.6.exe#md5=5e48c85a9ace1baad77dc26bb42ab4e1
 this download location was referenced by http://pypi.python.org/pypi/GDAL/

 In a cmd, window, I set path to include python, and try to run 
 geobase2osm:

 C:\OSMset 
 PATH=C:\OSM\Python26;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Cygwin\Bin;C:\Progr
 am Files\Vim\vim72;C:\Program Files\QuickTime\QTSystem\;C:\Program 
 Files\OpenVPN\bin

 C:\OSMpython
 Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit 
 (Intel)] on win32
 Type help, copyright, credits or license for more information.
  ^Z

 C:\OSMbin\geobase2osm.py
 C:\OSM\bin\geobase2osm.py:5: DeprecationWarning: the sets module is 
 deprecated
   import sets
 Traceback (most recent call last):
   File C:\OSM\bin\geobase2osm.py, line 10, in module
 import osgeo.ogr
   File C:\OSM\Python26\lib\site-packages\osgeo\ogr.py, line 7, in 
 module
 import _ogr
 ImportError: DLL load failed: The specified module could not be found.


 That line 7 has this:
 import _ogr

 Obviously it's trying to import something. Maybe the something is in a 
 python egg GDAL-1.6.1-py2.6-win32.egg 
 http://pypi.python.org/packages/2.6/G/GDAL/GDAL-1.6.1-py2.6-win32.egg#md5=0d187c3a78279a79a12085ac6ed78711
  
 that's listed on the GDAL python package page. I have no idea what to 
 do with a python egg but maybe it involves finding and installing 
 setuptools or maybe easy_install 

 

 John





 
 *From:* Frank Steggink stegg...@steggink.org
 *To:* JOHN SMART smarto...@rogers.com
 *Cc:* talk-ca@openstreetmap.org
 *Sent:* Sat, November 21, 2009 12:23:10 AM
 *Subject:* Re: [Talk-ca] Help for Canvec to OSM for part of NB

 Hi John,

 It's been a while ago since I installed this. I didn't have GDAL on my 
 machine before, so I'm using the latest version (still 1.6.2). And 
 after the installation I didn't bother about it anymore ;)

 Which OS are you using? If you're using Windows, then you should be 
 able to use the installer for the Python version you're using at the 
 bottom of the page. Maybe you also need to install GDAL 1.6.1, if 
 you're currently using an older version, but it might still work if 
 you have an older version. If you're not sure what to choose, you can 
 best try to contact Howard Butler. He is the author of these bindings, 
 and his e-mail address is listed on the page.

 If this doesn't work for you, I could make a number of files 
 available, which you can import. A while back I did that also for 
 someone else, which worked well.

 By the way, I forgot to add in my first mail that when you're using 
 the Geobase files, you'll have the same attributes which are used in 
 most of the country. This won't be the case for Canvec.

 Hope this helps,

 Frank

 JOHN SMART wrote:
  Hi Frank
 
  Thanks for your reply. I'll use the NRN data for now then. I have 
 grabbed the NB NRN files, no problem there.
 
  What I have done so far and where I am stuck now:
  -- following what's written in 
 http://wiki.openstreetmap.org/wiki/Geobase2osm:
  - installed python 2.6 (I already had python 2.something as part of 
 FWTools but python version is too early to support Shapely)
  - installed Shapely 1.0.14 under the Python directory tree
 
  but now I am stuck at installing OGR Python bindings osgeo.ogr 
 Python GDAL http://pypi.python.org/pypi/GDAL/
  Question: what, exactly, do I need to download and install here.
  Note that I already have the FWTools (http://fwtools.maptools.org) 
 installation which includes GDAL and OGR.
  What more / different do I need, to satisfy this Python bindings 
 requirement?
 
  Am I still on the right track?
 
  Thanks for any more help
  John
 
 
  
  *From:* Frank Steggink stegg...@steggink.org 
 mailto:stegg...@steggink.org
  *To:* John Smart smarto...@rogers.com mailto:smarto...@rogers.com
  *Cc:* talk-ca@openstreetmap.org mailto:talk-ca@openstreetmap.org
  *Sent:* Thu, November 19, 2009 11:33:29 PM
  *Subject:* Re: [Talk-ca] Help for Canvec to OSM for part of NB
 
  Hi John,
 
  Thanks for looking at the scripts. Please see below.
 
  John Smart wrote:
   Hello
  
   I would like

Re: [Talk-ca] Help for Canvec to OSM for part of NB

[Frank Steggink]

Hi John,

It's been a while ago since I installed this. I didn't have GDAL on my 
machine before, so I'm using the latest version (still 1.6.2). And after 
the installation I didn't bother about it anymore ;)

Which OS are you using? If you're using Windows, then you should be able 
to use the installer for the Python version you're using at the bottom 
of the page. Maybe you also need to install GDAL 1.6.1, if you're 
currently using an older version, but it might still work if you have an 
older version. If you're not sure what to choose, you can best try to 
contact Howard Butler. He is the author of these bindings, and his 
e-mail address is listed on the page.

If this doesn't work for you, I could make a number of files available, 
which you can import. A while back I did that also for someone else, 
which worked well.

By the way, I forgot to add in my first mail that when you're using the 
Geobase files, you'll have the same attributes which are used in most of 
the country. This won't be the case for Canvec.

Hope this helps,

Frank

JOHN SMART wrote:
 Hi Frank

 Thanks for your reply. I'll use the NRN data for now then. I have 
 grabbed the NB NRN files, no problem there.

 What I have done so far and where I am stuck now:
 -- following what's written in 
 http://wiki.openstreetmap.org/wiki/Geobase2osm:
 - installed python 2.6 (I already had python 2.something as part of 
 FWTools but python version is too early to support Shapely)
 - installed Shapely 1.0.14 under the Python directory tree

 but now I am stuck at installing OGR Python bindings osgeo.ogr Python 
 GDAL http://pypi.python.org/pypi/GDAL/
 Question: what, exactly, do I need to download and install here.
 Note that I already have the FWTools (http://fwtools.maptools.org) 
 installation which includes GDAL and OGR.
 What more / different do I need, to satisfy this Python bindings 
 requirement?

 Am I still on the right track?

 Thanks for any more help
 John


 
 *From:* Frank Steggink stegg...@steggink.org
 *To:* John Smart smarto...@rogers.com
 *Cc:* talk-ca@openstreetmap.org
 *Sent:* Thu, November 19, 2009 11:33:29 PM
 *Subject:* Re: [Talk-ca] Help for Canvec to OSM for part of NB

 Hi John,

 Thanks for looking at the scripts. Please see below.

 John Smart wrote:
  Hello
 
  I would like to take a shot at updating the OSM for some of New 
 Brunswick, which presently does not have very much mapping compiled. 
 The plan I think I'd like to follow is:
 
  1. Select an NTS 1:50 000 area that has few roads and which has no 
 OSM or minimal OSM.
  2. Run script(s) to generate OSM from the Canvec data set. At this 
 point I am only interested in roads, to prove the process for that.
  3. Upload the OSM.
  4. Have some people (you?) review the data, make comments.
  5. Iterate the process a bit till quality good (or I give up!)
  6. If I'm still here, maybe add some more.
 
  Any comments on my plan are very welcome, especially helpful tips!
  
 Regarding the road data, Canvec is derived from Geobase NRN, so it 
 might be better to use the latter. The CITS guys here should be able 
 to give a better answer ;) For Geobase NRN there is a different 
 script, named geobase2osm.py [1].With that it is possible to convert 
 certain areas (like a NTS tile) to an OSM file, and then you can use 
 JOSM to import the data. There is a wiki page describing the Geobase 
 process [2], but it still describes the convoluted process involving 
 RoadMatcher.

 The current process is:
 * create a bounds file for a certain area for geobase2osm.py
 * execute geobase2osm.py
 * download OSM data for this area from JOSM
 * open the resulting OSM file in JOSM
 * copy over the features which do not exist
 - make sure you connect the new roads to the existing roads in OSM
 - depending on the density of the data, it is generally better to 
 work in multiple iterations
 * upload the data to OSM
 - indicate in the description of the changeset that you imported data 
 from Geobase for tile 999x00.

 Several people on this list have experience with this process, so 
 don't hesitate to ask any questions you might have.

 For Canvec we're organizing a meeting in a few weeks, in order to get 
 some experience with the import, and to work on the process.
  The part I'm currently interested in is #2, generating OSM from 
 Canvec. I saw on the mailing list that there is a python script called 
 canvec_to_osm_features.py, and I have downloaded that. However, I have 
 difficulty running it on my Windows XP box. Specifically:
  - I can launch python (which I happen to have on my path)
  - But if I just run C:\Canvec2Osmpython canvec_to_osm_features.py 
 --version then nothing happens.
 
  I'd appreciate any comments on exactly what I need to do to get this 
 .py script to work.
  
 The script you should execute is canvec-to-osm.py. :) The other script 
 only contains the list of features which should

Re: [Talk-ca] Help for Canvec to OSM for part of NB

[Frank Steggink]

Hi John,

I've converted one NTS tile (021N08, Edmunston), and uploaded it here: 
[1] This way you can give it a try right away, in case you get stuck 
with the installation of the GDAL bindings. The Edmunston area 
corresponds with the following location in OSM: [2] . You can paste that 
URL directly into JOSM, in order to download data for that area.

One thing what is odd is that there are really a lot of nodes in this 
file. I haven't seen this to this extent in the Quebec data. It would be 
better to clean this up somehow, but it could also be done at a later 
time. Because of this, and also in order to keep the work manageable, it 
is important to upload small chunks. (Small = about a couple of thousand 
of nodes.) There are already some roads in Edmunston itself, so you only 
had to add missing roads.

When importing data, it works best to do cleanup immediately, or shortly 
after the import. This is connecting nodes, removing duplicate nodes, 
other inconsistencies, etc. It would be much more tedious if this needs 
to be done at a later moment. If you don't use it already, please check 
out the Validator plugin of JOSM, and learn how to use it.

Frank

[1] http://www.steggink.org/osm/Geobase_NB_021N/021n08_out.osm.zip
[2] 
http://www.openstreetmap.org/index.html?mlat=47.375mlon=-68.25minlat=47.25minlon=-68.5maxlat=47.5maxlon=-68box=yeslayers=B000FTF


Frank Steggink wrote:
 Hi John,

 It's been a while ago since I installed this. I didn't have GDAL on my 
 machine before, so I'm using the latest version (still 1.6.2). And after 
 the installation I didn't bother about it anymore ;)

 Which OS are you using? If you're using Windows, then you should be able 
 to use the installer for the Python version you're using at the bottom 
 of the page. Maybe you also need to install GDAL 1.6.1, if you're 
 currently using an older version, but it might still work if you have an 
 older version. If you're not sure what to choose, you can best try to 
 contact Howard Butler. He is the author of these bindings, and his 
 e-mail address is listed on the page.

 If this doesn't work for you, I could make a number of files available, 
 which you can import. A while back I did that also for someone else, 
 which worked well.

 By the way, I forgot to add in my first mail that when you're using the 
 Geobase files, you'll have the same attributes which are used in most of 
 the country. This won't be the case for Canvec.

 Hope this helps,

 Frank

 JOHN SMART wrote:
   
 Hi Frank

 Thanks for your reply. I'll use the NRN data for now then. I have 
 grabbed the NB NRN files, no problem there.

 What I have done so far and where I am stuck now:
 -- following what's written in 
 http://wiki.openstreetmap.org/wiki/Geobase2osm:
 - installed python 2.6 (I already had python 2.something as part of 
 FWTools but python version is too early to support Shapely)
 - installed Shapely 1.0.14 under the Python directory tree

 but now I am stuck at installing OGR Python bindings osgeo.ogr Python 
 GDAL http://pypi.python.org/pypi/GDAL/
 Question: what, exactly, do I need to download and install here.
 Note that I already have the FWTools (http://fwtools.maptools.org) 
 installation which includes GDAL and OGR.
 What more / different do I need, to satisfy this Python bindings 
 requirement?

 Am I still on the right track?

 Thanks for any more help
 John


 
 *From:* Frank Steggink stegg...@steggink.org
 *To:* John Smart smarto...@rogers.com
 *Cc:* talk-ca@openstreetmap.org
 *Sent:* Thu, November 19, 2009 11:33:29 PM
 *Subject:* Re: [Talk-ca] Help for Canvec to OSM for part of NB

 Hi John,

 Thanks for looking at the scripts. Please see below.

 John Smart wrote:
 
 Hello

 I would like to take a shot at updating the OSM for some of New 
   
 Brunswick, which presently does not have very much mapping compiled. 
 The plan I think I'd like to follow is:
 
 1. Select an NTS 1:50 000 area that has few roads and which has no 
   
 OSM or minimal OSM.
 
 2. Run script(s) to generate OSM from the Canvec data set. At this 
   
 point I am only interested in roads, to prove the process for that.
 
 3. Upload the OSM.
 4. Have some people (you?) review the data, make comments.
 5. Iterate the process a bit till quality good (or I give up!)
 6. If I'm still here, maybe add some more.

 Any comments on my plan are very welcome, especially helpful tips!

   
 Regarding the road data, Canvec is derived from Geobase NRN, so it 
 might be better to use the latter. The CITS guys here should be able 
 to give a better answer ;) For Geobase NRN there is a different 
 script, named geobase2osm.py [1].With that it is possible to convert 
 certain areas (like a NTS tile) to an OSM file, and then you can use 
 JOSM to import the data. There is a wiki page describing the Geobase 
 process [2], but it still describes the convoluted process involving

[Talk-ca] Canvec Import Party Sherbrooke

[Frank Steggink]

Hi all,

Hereby I would like to announce the Canvec Import Party, which will be 
held in Sherbrooke, Québec, on December 5th. It has been referred to as 
the couch mapping party, but at the intended location there are no 
couches available ;) The location is a computer lab at the University of 
Sherbrooke, so it is not strictly necessary to bring your own gear.

We'll mostly talk about the import of Canvec data into OSM, in which 
we'll put the discussed approach(es) to practice. Attention will be 
given to things like the process, tools, etc. Furthermore we'll spend 
some time on the remainder of the NRN import, as well as maintenance 
aspects. It would also be good to evaluate the topic of attribution.

We'll try to make a connection via Skype available, so people who are 
not able to attend, can still follow the proceedings over the Internet.

Details:

Agenda OSM meeting Sherbrooke - Couch(less?) Mapping Party / Canvec 
Import Party

When: Saturday December 5th, 2009, 10:00-16:00
Where: Université de Sherbrooke (exact location to be confirmed)
Location: http://osm.org/go/ck...@hy

Topics:
- Geobase NRN import
  - Using JOSM + Validator plugin
- Lunch
- Canvec import
  - Process
  - Tools
  - Conversion script
  - Challenges
  - Import
  - Finetuning of import process
- Further imports
  - Geobase NHN
- 5-à-7 ?

So, if you happen to be in the neighborhood and want to say hi, or you 
definitely want to be present at the hot zone of the Canvec import, 
please let Michel, Yves and/or me know that you're coming.

Cheers,

Frank

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

Re: [Talk-ca] Help for Canvec to OSM for part of NB

[Frank Steggink]

Hi John,

Thanks for looking at the scripts. Please see below.

John Smart wrote:
 Hello

 I would like to take a shot at updating the OSM for some of New 
 Brunswick, which presently does not have very much mapping compiled. The 
 plan I think I'd like to follow is:

 1. Select an NTS 1:50 000 area that has few roads and which has no OSM 
 or minimal OSM.
 2. Run script(s) to generate OSM from the Canvec data set. At this point 
 I am only interested in roads, to prove the process for that.
 3. Upload the OSM.
 4. Have some people (you?) review the data, make comments.
 5. Iterate the process a bit till quality good (or I give up!)
 6. If I'm still here, maybe add some more.

 Any comments on my plan are very welcome, especially helpful tips!
   
Regarding the road data, Canvec is derived from Geobase NRN, so it might 
be better to use the latter. The CITS guys here should be able to give a 
better answer ;) For Geobase NRN there is a different script, named 
geobase2osm.py [1].With that it is possible to convert certain areas 
(like a NTS tile) to an OSM file, and then you can use JOSM to import 
the data. There is a wiki page describing the Geobase process [2], but 
it still describes the convoluted process involving RoadMatcher.

The current process is:
* create a bounds file for a certain area for geobase2osm.py
* execute geobase2osm.py
* download OSM data for this area from JOSM
* open the resulting OSM file in JOSM
* copy over the features which do not exist
  - make sure you connect the new roads to the existing roads in OSM
  - depending on the density of the data, it is generally better to 
work in multiple iterations
* upload the data to OSM
  - indicate in the description of the changeset that you imported data 
from Geobase for tile 999x00.

Several people on this list have experience with this process, so don't 
hesitate to ask any questions you might have.

For Canvec we're organizing a meeting in a few weeks, in order to get 
some experience with the import, and to work on the process.
 The part I'm currently interested in is #2, generating OSM from Canvec. 
 I saw on the mailing list that there is a python script called 
 canvec_to_osm_features.py, and I have downloaded that. However, I have 
 difficulty running it on my Windows XP box. Specifically:
 - I can launch python (which I happen to have on my path)
 - But if I just run C:\Canvec2Osmpython canvec_to_osm_features.py 
 --version then nothing happens.

 I'd appreciate any comments on exactly what I need to do to get this .py 
 script to work.
   
The script you should execute is canvec-to-osm.py. :) The other script 
only contains the list of features which should be imported. I separated 
it to make it easier to manage. (Unfortunately the second script file 
contains underscores, but I'll update that soon. Maybe I should just 
rename it to features.py, so that it is immediately obvious that this 
script should not be called directly.)
 Lastly (for now) I think that if I get the .py working, I will 
 immediately run into a problem with shp-to-osm. Like the .py readme 
 said, I have made a bin directory and I've put the shp-to-osm in there. 
 Actually I have both:
 2009-11-11  17:37 7,365,493 
 shp-to-osm-0.7.3-jar-with-dependencies.jar
 2009-11-11  17:37 7,365,493 shp-to-osm.jar
 in case there is some naming problem. Have I done the right thing?
   
Ian Dees always uses the longer name when building the jar file, so you 
only have to keep the first one. You'll learn quickly enough if the jar 
file can't be found for some reason :)

 Thanks for any help. I hope I won't get frustrated and that I'll be able to 
 help the project a bit!
Helping us would be wonderful. Especially New Brunswick still has large 
white areas, so it would be excellent to see that filled up!

Cheers,

Frank

[1] http://wiki.openstreetmap.org/wiki/Geobase2osm
[2] http://wiki.openstreetmap.org/wiki/Geobase



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

[Talk-ca] Python version of canvec-to-osm

[Frank Steggink]

Hi,

I have created a python version of canvec-to-osm. It does basically the 
same as Sam's batch files. With it, 1 or 16 tiles are downloaded, 
converted, and put in a ZIP file.

The script can be found here:
http://www.steggink.org/osm/Canvec/Canvec-to-osm_v0.1.zip

Requirements:
- Python 2.6 (recommended) or 2.5: http://www.python.org/
- Java Runtime Environment: http://www.java.com/
- recent version of shp-to-osm: 
http://redmine.yellowbkpk.com/projects/list_files/geo

I've tested the script both on Windows and Linux (Ubuntu) with 
shp-to-osm 0.7.1 - 0.7.3.
The rules files come from Sam's canvec-to-osm script, version 0.9.6.0. 
They are not the final rules files which should be available in a few 
weeks. If you want to add more features, or exclude some features from 
being processed, you can easily add / remove lines from 
canvec_to_osm_features.py.

The configuration of this script is part of the script itself (for now). 
The default should be enough to get you going, so it is not necessary to 
change the configuration. You can do this, if you already have an 
existing directory to store Canvec SHP data. The script does not attempt 
to modify the feature geometries. This should be done by more 
specialized scripts / applications. I haven't looked in that.

Detailed instructions can be found in the readme. Questions and feedback 
are welcome.

Regards,

Frank

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

Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available

[Frank Steggink]

Sam Vekemans wrote:
 Im not making a new script, the folks who understand python, are
 making a script that can solve the 'duplicate intersecting nodes' and
 'inner/outer relation' problem.

 (Yes you might have fixed it, but i've reached the crux of my
 technical ability)

 Sure, they can use java, if that works for them.

 Im just isolating my canvec-to-osm script to handle the 80 map
 features that i know converts correctly. The other 10 can be dealt
 with using another option.

 Since i dont know how to program (accept in basic DOS) im not that much help.

 Others who are experienced in python  java are welcome to take the lead.

 Frank already started to help out maptastically :)

 Sam

 On 11/6/09, Ian Dees ian.d...@gmail.com wrote:
   
 On Nov 6, 2009, at 9:28 PM, Sam Vekemans
 acrosscanadatra...@gmail.com wrote:

 
 This python script is yet to be made 'canvec2osm.py' its open to
 anyone to make, and i recommend that who ever does, its ONLY 1 person
 who is in charge of maintaining the script.
   
 Why are you creating another shp to osm converter? Is there something
 the existing tools don't do? I thought you were using shp-to-osm? What
 changed?
 

Hi Sam,

The idea what I mentioned is to convert your batch files to Python. The 
main reason for that is that this way people using Linux or other OSs 
can also perform this conversion locally. I know you want to convert all 
of Canada yourself, but that is still a lot of work. Many hands make 
light work. The only thing we should be concerned about is that we're 
all using the same rule file. This is the most vital part in ensuring 
consistency across the country.

To Ian: shp-to-osm won't disappear in the process. Sam's batch files are 
still calling it. It would be pointless to create a second version. 
There is already a Python script with the same name, but it was written 
specifically for the MassGIS import.

Sam, can you give some additional clarification what your intentions 
are? I'm afraid I'm not following them well. When you mentioning 
removing duplicate nodes and relations, it looks as if you intend to 
create a script which does some post-processing. Is that correct? I 
haven't started anything in that area. (I actually still need to start 
with the Python version of your batch script, but I'm going to work on 
that today.)

Now we're talking on this: in shp-to-osm (Java) tags are now put 
properly on the multipolygon relationship. They also still appear on the 
inner polygons (mentioned to Ian already), but that should be fixed.

Since shp-to-osm is called for one feature type at a time, there are 
some new challenges when multiple feature types are involved. I guess 
you've been thinking about that already. Duplicate nodes will become an 
issue when you have for example a residential area with an adjacent 
wooded area (assuming that the boundaries are matching exactly). It will 
be difficult to deal with this. I'm not sure if it would be technically 
possible to adjust shp-to-osm for that, but the result will be that the 
files will become huge. They already have to be split up for certain 
feature types, and I don't think it is possible to use the same set of 
IDs over multiple output files.

 From what I understand about the upload process (and someone please 
correct me if this isn't right), the OSM server will return new ID 
numbers for any nodes, ways, and relationships uploaded. In the OSM 
files generated by Ian, and also when you're editing in JOSM yourself, 
temporary IDs are assigned. They have a negative value, which indicates 
that these objects don't exist on the server. So, this means that, after 
you have uploaded file00.osm, and you open file01.osm, JOSM or the 
server do no longer remember to what objects any IDs are _referring_ to, 
if those objects are not _defined_ in the same file.

The same issue is going on with multipolygon relationships, where a part 
of the ways are reused. This can only happen if everything is defined in 
the same file. And such a file will be way too large to upload safely to 
the server. Recently I noticed that if you want to create/update/delete 
about 10k objects the server is going to act difficult. Regarding 
relationships, and reuse of the geometry: I think that we have not only 
to remove duplicate nodes, but also split up ways, otherwise the JOSM 
validator will complain about overlapping ways. A way can be used in 
multiple relationships.

A third thing which might need to be resolved are map features which 
cross the boundary of the NTS tiles. Do we want to merge them? If these 
features have the same Geobase metadata (ID, etc.), then it shouldn't be 
a big problem, otherwise we need to decide whether we prefer to keep the 
metadata, or if we want to have merged features.

All of this means we can't do anything to clean up the data. Sure we 
can, but this can only be done after an initial upload to the server. 
That way we can still apply any logic to deal with 

Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available

[Frank Steggink]

Hi Ian,

Ian Dees wrote:
 On Sat, Nov 7, 2009 at 8:59 AM, Frank Steggink stegg...@steggink.org 
 mailto:stegg...@steggink.org wrote:

 Sam, can you give some additional clarification what your
 intentions are? I'm afraid I'm not following them well. When you
 mentioning removing duplicate nodes and relations, it looks as if
 you intend to create a script which does some post-processing. Is
 that correct? I haven't started anything in that area. (I actually
 still need to start with the Python version of your batch script,
 but I'm going to work on that today.)


 Are these duplicate nodes/relations being created by the converter or 
 are they in the source data?
I'm talking mostly from my experience with Geobase. When roads are 
imported, where there is already data from an adjacent tiles, nodes get 
duplicated. This also happens when I copy over Geobase data multiple times.

I'm not sure how this works out for the Canvec data, because there are 
already multiple files. However, if features in multiple files are 
touching each other, their nodes will be identified as duplicates. This 
is also true for adjacent NTS tiles. The problem with shp-to-osm which I 
found earlier this week has already been fixed :)
  Now we're talking on this: in shp-to-osm (Java) tags are now put 
 properly on the multipolygon relationship. They also still appear on 
 the inner polygons (mentioned to Ian already), but that should be fixed.

 Tags appears on the inner ways because you have an inner rule in the 
 rules.txt file. If you remove those lines from the rules.txt, you 
 should end up with no tags on inner ways of multipolygons. If this 
 doesn't happen, then it's a bug and I will fix it.
OK, that could explain why this is happening. I'll look at it, and share 
my observations.
  

 Since shp-to-osm is called for one feature type at a time, there
 are some new challenges when multiple feature types are involved.
 I guess you've been thinking about that already. Duplicate nodes
 will become an issue when you have for example a residential area
 with an adjacent wooded area (assuming that the boundaries are
 matching exactly). It will be difficult to deal with this. I'm not
 sure if it would be technically possible to adjust shp-to-osm for
 that, but the result will be that the files will become huge. They
 already have to be split up for certain feature types, and I don't
 think it is possible to use the same set of IDs over multiple
 output files.


 I do have a relationificator plugin started for shp-to-osm that will 
 attempt to solve this problem by converting exactly-overlapping edges 
 into relations and delete duplicate primitives. If there's a strong 
 need for it I can continue to work on it.
That sounds very interesting. I guess this only works within the single 
shape file which is being converted, correct? What is the behavior if a 
file has to be split up, because it becomes too large?
  

 From what I understand about the upload process (and someone
 please correct me if this isn't right), the OSM server will return
 new ID numbers for any nodes, ways, and relationships uploaded. In
 the OSM files generated by Ian, and also when you're editing in
 JOSM yourself, temporary IDs are assigned. They have a negative
 value, which indicates that these objects don't exist on the
 server. So, this means that, after you have uploaded file00.osm,
 and you open file01.osm, JOSM or the server do no longer remember
 to what objects any IDs are _referring_ to, if those objects are
 not _defined_ in the same file. 


 The same issue is going on with multipolygon relationships, where
 a part of the ways are reused. This can only happen if everything
 is defined in the same file. And such a file will be way too large
 to upload safely to the server. Recently I noticed that if you
 want to create/update/delete about 10k objects the server is going
 to act difficult. 


 I normally upload my NHD changesets with 40k-50k changes in each 
 upload without problem. It takes an hour or so to apply (depending on 
 server load), but it works without error.
What program are you using for the upload? Is it bulk-upload, JOSM, or 
something else? I'm using JOSM, because I had problems with bulk-upload. 
If there is something better and more robust (the upload with JOSM fails 
when there are about 10k changes), I would certainly give it a try.
  

 Regarding relationships, and reuse of the geometry: I think that
 we have not only to remove duplicate nodes, but also split up
 ways, otherwise the JOSM validator will complain about overlapping
 ways. A way can be used in multiple relationships.


 This would also happen with the relationificator.
  

 A third thing which might need to be resolved are map features
 which cross the boundary of the NTS tiles. Do we want to merge
 them

Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available

[Frank Steggink]

Ian Dees wrote:

 I normally upload my NHD changesets with 40k-50k changes in each
 upload without problem. It takes an hour or so to apply (depending
 on server load), but it works without error.

 What program are you using for the upload? Is it bulk-upload,
 JOSM, or something else? I'm using JOSM, because I had problems
 with bulk-upload. If there is something better and more robust
 (the upload with JOSM fails when there are about 10k changes), I
 would certainly give it a try.


 I use JOSM -- I check upload as one changeset and check close 
 changeset after upload. I usually try to do this when the load on the 
 database and ruby workers are low.
OK thanks. I've seen this option, and I've only tried it once. This was 
with a small upload only. I did not think of trying it with a large 
changeset.

Regarding the inner rules: I've just checked it, and this is working 
as you mentioned. Great :) I also tried the -t option, with comparison 
on file level, and any ways used in a relation are being kept. As far as 
I'm concerned, this version of shp-to-osm is good to go, if we're not 
going to deal with any of the additional issues we discussed this morning.

Great job Ian!

Frank

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

Re: [Talk-ca] canvec / shp-to-osm -multi-polygons -residential area

[steggink]

Quoting Sam Vekemans acrosscanadatra...@gmail.com:

 Ok,
 for the residential area, i have the tags in the relation, and not on
 the outer, nor on the inner.

 Is that OK?
 It still renders (i would think)

 Sam


Hi Sam,

The Multipolygon wiki page [1] explains it better than I could do:

The intended use of multipolygons is this:

 * Tags describing the multipolygon should go on the outer way.
 * If the inner way represents something in itself (e.g. a forest  
with a hole where the hole is a lake), then the inner way may be  
tagged as such.
 * Otherwise the inner way(s) should be left untagged.
 * The direction of the ways does not matter.
 * If there is no role given outer is assumed, this makes defining  
boundaries easier as no explicit outer role is needed for all the  
elements (which can be in the hundreds). But to avoid ambiguity the  
role should be set in case there are inner elements.
 * name tags of the relation are rendered by mapnik but not by  
osmarender.

Frank

[1] http://wiki.openstreetmap.org/wiki/Multipolygon


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

Re: [Talk-ca] canvec / shp-to-osm

[Frank Steggink]

Hi Sam,

I've just downloaded some CanVec data, and had a look at sheets 031I07 
and -08. I wonder what you mean by uploading all sub-residential 
files. I understand that the data is separated over multiple files, 
because of certain limitations. In the residential OSM files I also see 
no polygons with a multipolygon relationship of outer. So,this means 
that the outlines of places like Trois-Rivieres and others are missing. 
The same issue is going on with wooded areas. The data is converted with 
Canvec2OSM version 0.9.4.

I had a closer look at the raster file (from Toporama) of sheet 031I08, 
because there is much less data, and I looked at the village of Gentilly 
(see [1]). This is in the center of the sheet. The raster file suggests 
that a multipolygon relationship should be in place, but the vector file 
(BS_1370009_2_Residential_area0.osm) shows only the two inner polygons. 
Are the outer polygons stored in a different file, or are they not 
converted at all? The shape of the outer polygon doesn't look to be 
complex, so I don't think the max_nodes threshold would be exceeded. 
Looking at the OSM file: there is only one multipolygon relationship in 
it, but it only refers to the two inner polygons, and not to any outer 
polygon at all.

One note regarding multipolygons: the inner polygons shouldn't have any 
tags at all. See [2].

Anyways, some clarifications about what is going on, and how the data 
should be interpreted would be welcome. I'm reluctant to import data 
which looks not correct. For the rest, keep up your good work :)

Regards,

Frank

[1] http://osm.org/go/cKHX9ApT-
[2] http://wiki.openstreetmap.org/wiki/Multipolygon

Sam Vekemans wrote:
 Hi Richard,
 i think your refering to the large multi-polygons such as
 'residential_area', and it 'appears' to be inverted.

 Here's the majic; when all the sub- residential.osm files are uploaded
 to OSM, it renders correctly.
 In JOSM, you need to zoom out and load the area, to see it.

 I think i'll load a region of NFLD in the next cuple days to test my 
 hypothises.

 Sam

 ps. I cc'd talk-ca as this was mentioned b4.

 On 9/22/09, Richard Weait rich...@weait.com wrote:
   
 Dear gentlemen,

 I've had a look at some of Sam's test areas.  In 1435 files there are
 zero occurrences of Relation=outer.

 So at some point we started calling relation=outer, relation=inner or
 completely dropping outer relations by mistake.

 I do still see rare nested ways, but both are marked as inner, and are
 on separate layers after --maxnodes

 I've run 0.6.1 again with an old rules file and see the same problem
 so I believe that this is an issue in shp-to-osm.

 Ian can you check a 0.5.0 - generated file and see if it contains any
 outer?

 Best regards,
 Richard

 


   


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

Re: [Talk-ca] canvec / shp-to-osm

[Frank Steggink]

Hi,

I think to know what is going on. I've tried to convert the residential 
areas of 031I08 myself, and I got an OSM file with an outer polygon. 
However, the outer polygon has no tags. Also, it looks that Sam's batch 
files run shp-to-osm with the -t parameter, which suppresses the output 
of features without any tags.

Solution:
* shp-to-osm needs to be adjusted, so that the outer polygon will get 
the tags, but the inner polygons will not.
* shp-to-osm should be called without the -t parameter.
Is this possible?

Frank

Frank Steggink wrote:
 Hi Sam,

 I've just downloaded some CanVec data, and had a look at sheets 031I07 
 and -08. I wonder what you mean by uploading all sub-residential 
 files. I understand that the data is separated over multiple files, 
 because of certain limitations. In the residential OSM files I also see 
 no polygons with a multipolygon relationship of outer. So,this means 
 that the outlines of places like Trois-Rivieres and others are missing. 
 The same issue is going on with wooded areas. The data is converted with 
 Canvec2OSM version 0.9.4.

 I had a closer look at the raster file (from Toporama) of sheet 031I08, 
 because there is much less data, and I looked at the village of Gentilly 
 (see [1]). This is in the center of the sheet. The raster file suggests 
 that a multipolygon relationship should be in place, but the vector file 
 (BS_1370009_2_Residential_area0.osm) shows only the two inner polygons. 
 Are the outer polygons stored in a different file, or are they not 
 converted at all? The shape of the outer polygon doesn't look to be 
 complex, so I don't think the max_nodes threshold would be exceeded. 
 Looking at the OSM file: there is only one multipolygon relationship in 
 it, but it only refers to the two inner polygons, and not to any outer 
 polygon at all.

 One note regarding multipolygons: the inner polygons shouldn't have any 
 tags at all. See [2].

 Anyways, some clarifications about what is going on, and how the data 
 should be interpreted would be welcome. I'm reluctant to import data 
 which looks not correct. For the rest, keep up your good work :)

 Regards,

 Frank

 [1] http://osm.org/go/cKHX9ApT-
 [2] http://wiki.openstreetmap.org/wiki/Multipolygon

 Sam Vekemans wrote:
   
 Hi Richard,
 i think your refering to the large multi-polygons such as
 'residential_area', and it 'appears' to be inverted.

 Here's the majic; when all the sub- residential.osm files are uploaded
 to OSM, it renders correctly.
 In JOSM, you need to zoom out and load the area, to see it.

 I think i'll load a region of NFLD in the next cuple days to test my 
 hypothises.

 Sam

 ps. I cc'd talk-ca as this was mentioned b4.

 On 9/22/09, Richard Weait rich...@weait.com wrote:
   
 
 Dear gentlemen,

 I've had a look at some of Sam's test areas.  In 1435 files there are
 zero occurrences of Relation=outer.

 So at some point we started calling relation=outer, relation=inner or
 completely dropping outer relations by mistake.

 I do still see rare nested ways, but both are marked as inner, and are
 on separate layers after --maxnodes

 I've run 0.6.1 again with an old rules file and see the same problem
 so I believe that this is an issue in shp-to-osm.

 Ian can you check a 0.5.0 - generated file and see if it contains any
 outer?

 Best regards,
 Richard

 
   
   
 


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

   


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

Re: [Talk-ca] Correcting Geobase_import_2009

[Frank Steggink]

Hi John,

I personally think it would be better to do the cleanup immediately 
after the import, or possible during the import. Of course it is very 
tedious to do so, and it will slow down the import, but the person who 
is doing the import, knows best which roads were omitted. The goal is 
not to import as fast as possible (it's not a match), but to get high 
quality data.

Here is the process I have done so far. When using the process with 
RoadMatcher, I made sure that only missing roads are imported. Since 
RoadMatcher isn't working perfectly, I added or removed some features 
which should be imported. Then I uploaded the data, and after the 
upload, I downloaded the area again, and made the connections.

Yesterday and today I happened to have imported a few sheets, where I 
haven't used RoadMatcher, because it isn't working terribly well. What I 
have done is basically Sam's more recent suggestion, to convert the 
Geobase data to separate OSM files, and copy the features over which 
should be imported. When doing that I made the connections immediately, 
using the validator tools in JOSM to ensure that I haven't forgotten 
anything.

It is slow, but after a while you get used to it, and you're able to 
make more progress. So far, in nearly all of the cases I just extended / 
shortened the Geobase segments, because the deviations weren't that big. 
It didn't warrant the introduction of new segments, and it is also 
inevitable that Geobase data would never be edited by a different person.

By the way, a tool that is useful, and which now has worldwide coverage 
is KeepRight: [1]. It also detects missing intersections / overlapping 
roads, and even stuff like one-way dead ends. There are many different 
checks, which will all help us improving the data in OpenStreetMap.

Frank

[1] http://keepright.ipax.at/

John Whelan wrote:
 I found both James's and Sam's comments very useful.  It gives me a 
 much clearer idea of what you are trying to do and the limitations 
 involved.  It would appear that we have the ability to identify roads 
 omitted from the geobase import which means at some point in time 
 given enough resources a clean up could be done.  Until then as you 
 say areas where one road is already in OSM that have a number of 
 residential roads connected to it can be cleaned up on an if spotted 
 basis.  So be it.

 Thanks

 Cheerio John



 Adam Dunn wrote:
 In JOSM, another way to quickly add on to a way like that is to use 
 the select tool to select the way you will be adding on to, holding 
 the shift (or control) key, selecting the last node in the way, then 
 use the draw (add) tool to continue drawing the way. By default, in 
 JOSM, if you have a node selected that only belongs to one way, and 
 you start using the draw tool, that way will be extended, including 
 tags. However, if a node belongs to multiple ways (an intersection), 
 then a brand new way will be created (since it doesn't know which of 
 the ways to extend), and you have to do a combine operation. So 
 selecting a node and a way together tells JOSM which of the ways you 
 want to extend.

 To copy tags from one way to another, you can use the paste tags 
 operation. Select the way to take the tags from, and use the copy 
 operation (ctrl-c). At this point you have the choice of pasting the 
 entire way (ctrl-v), or just pasting the tags (ctrl-shift-v) into an 
 existing way. When you paste tags it will overwrite tags with new 
 values if they already exist, but will leave tags intact if there is 
 no new tag value coming in (there is no dialog to merge, at least on 
 version 2300). One unfortunate aspect of doing this with GeoBase is 
 that GeoBase assigns a new uuid to a way separated by an intersection 
 (ie. a road will be split into separate ways ever time there is an 
 intersection, and each of those ways gets a unique uuid)

  I've learnt over the years with databases that some idiot 
 somewhere will invariably want to use a tag like this and not realise 
 that some roads don't have a value.

 If some idiot is using the OSM data in a manner that assumes some 
 tag exists, then they won't get very far at all. OSM allows anyone to 
 use whatever tags they want, by allowing any combination of keys and 
 values. All tags that are used in OSM are merely *suggestions* and 
 are not mandatory. It would be foolish to assume even the simple such 
 as highway=tertiary will exist on tertiary roads. Having said that, 
 it would be nice to have as much information as possible taken in 
 from government sources. That is why Sam V is advocating making .osm 
 files available for people to obtain, so that people without 
 postgis/sql/roadmatcher experience can still use josm to copy over 
 the stuff that they want. There has been much discussion on how to 
 make this as automatic as possible, but uuid can only do so much 
 Anybody can get their hands on the GeoBase data and start copying 
 tags over if they want. The 

Re: [Talk-ca] canvec / shp-to-osm

[Frank Steggink]

Hi Sam,

It's either that you'll end up with 0 byte files, or with files without 
any outer polygons. The former is just an inconvenience, while the 
latter is a problem. ;)

Anyways, before you generate new data, I think someone should have a 
look at shp-to-osm, to check if my assumption that the tags are written 
to the wrong polygons (inner polygon, instead of outer polygon) is 
right. I could give it a try, but I'm not very familiar with Java, so I 
hope that Ian or someone who is more knowledgeable is willing to check 
this out. And maybe the working of the -t switch should be revisited, so 
that tagless elements which are part of a multipolygon relationship are 
still exported.

I'll have a look at the extra file, to see if it contains the data with 
outer polygons, although I actually want to upload one other sheet 
tonight. Regarding the nodes: I'm using JOSM to upload data, and 
although this might not be the most ideal solution, it is working fine. 
I've uploaded more than 1 elements at once, and I just uploaded more 
than 5000 elements (see [1], sheet 031I01), so this is still possible 
with JOSM. Anyways, what good is a bulk upload tool, if it doesn't 
really support bulk ;)

By the way, I also uploaded the residential areas of sheet 031I08. I've 
copied the tags of the shape of Gentilly to the outer polygon, removed 
them from the inner polygons, and uploaded the data. It looks OK in OSM. 
(Actually, I don't think that the CanVec residential areas are that 
good, but at least they correspond to the areas in the raster file.)

Frank

[1] http://www.openstreetmap.org/browse/changeset/2952729

Sam Vekemans wrote:


 On Sun, Oct 25, 2009 at 3:15 PM, Frank Steggink stegg...@steggink.org 
 mailto:stegg...@steggink.org wrote:

 Hi,

 I think to know what is going on. I've tried to convert the
 residential areas of 031I08 myself, and I got an OSM file with an
 outer polygon. However, the outer polygon has no tags. Also, it
 looks that Sam's batch files run shp-to-osm with the -t parameter,
 which suppresses the output of features without any tags.

 Solution:
 * shp-to-osm needs to be adjusted, so that the outer polygon will
 get the tags, but the inner polygons will not.


 Im running the script how with that change.. to see how it works...
  

 * shp-to-osm should be called without the -t parameter.
 Is this possible?

 However, that means for tiles that have no residential areas a file 
 with the size of 0 bytes will be created.   (not a problem, as i could 
 do that for all the features... but you'd end up with 80 0meg files.   
 that would cause a headache when someone looks at it for the 1st 
 time)  ... or we could just do that for residential areas.
  
 What i DID do was create an 'extra' file, in the 'extra' folder, that 
 extended the max nodes to 2 million. (or i could just remove that 
 toggle), and a full .osm file will be created.
 ... but remember that the API can only handle 2000 nodes. 

 and what i also did was create a 3rd line on the bat file that  omits 
 the '-t' and also in the 'extra' folder, as that should do the trick.

 Frank

 Frank Steggink wrote:

 Hi Sam,

 I've just downloaded some CanVec data, and had a look at
 sheets 031I07 and -08. I wonder what you mean by uploading all
 sub-residential files. I understand that the data is
 separated over multiple files, because of certain limitations.
 In the residential OSM files I also see no polygons with a
 multipolygon relationship of outer. So,this means that the
 outlines of places like Trois-Rivieres and others are missing.
 The same issue is going on with wooded areas. The data is
 converted with Canvec2OSM version 0.9.4.

 I had a closer look at the raster file (from Toporama) of
 sheet 031I08, because there is much less data, and I looked at
 the village of Gentilly (see [1]). This is in the center of
 the sheet. The raster file suggests that a multipolygon
 relationship should be in place, but the vector file
 (BS_1370009_2_Residential_area0.osm) shows only the two inner
 polygons. Are the outer polygons stored in a different file,
 or are they not converted at all? The shape of the outer
 polygon doesn't look to be complex, so I don't think the
 max_nodes threshold would be exceeded. Looking at the OSM
 file: there is only one multipolygon relationship in it, but
 it only refers to the two inner polygons, and not to any outer
 polygon at all.

 One note regarding multipolygons: the inner polygons shouldn't
 have any tags at all. See [2].


 Ya, i noticed that with the water features i was playing with the 
 other day. So that needs to have a closer look into.


 Anyways, some clarifications about what is going on, and how
 the data should

[Talk-ca] New user adding data, not sure what to do

[Frank Steggink]

Hi list,

I just _knew_ it would happen. As soon as I would start the Geobase 
import, some user would step up, and start adding data to the areas I'm 
about to import. And this is exactly what happened. To my surprise I 
discovered a whole lot of data southeast of Quebec City, in the 
Chaudière-Appalaches region: [1]. These are the NTS tiles 021L09, 10, 
15, and 16.

At first I was happy that there was some considerable activity in the 
Quebec region, other than my own. After examining the data, it comes 
from a user (Robert66) who has only joined us on Monday. Unfortunately 
this shines through his data as well: most of his roads are not 
connected, so that would involve a lot of cleanup. Apparently he had a 
blast this week: many small towns and villages were added. The data even 
has street names! See for example Montmagny: [2]. So, I've contacted him 
yesterday, in order to ask for more information. I haven't received a 
reply yet, but one day isn't that much.

Because this area was on my todo list, I decided to continue with my 
import. Tile 021L10 ([3]) is on tonight's program. After the data was 
loaded, I noticed a concentration of roads in St. Damien [4], which I 
didn't see yesterday. Apparently Robert66 was busy adding it today, see 
changeset 2451637. When zooming in, I noticed that, while the data 
looked topologically correct (apart from the fact that the roads aren't 
connected), many roads are displaced, up to 150 m, compared to the 
Geobase data. See [5], screenshot of OpenJump. Brown=OSM, green=Geobase. 
I know that Geobase isn't the most accurate dataset, but in the area I 
have imported data, it generally matched my roads reasonably well. The 
differences are up to 30 meters, although there are some exceptions. An 
example is the main road in the St. Damien screenshot, going from SW to 
NE. It was originally added by me, nearly a year ago: [6], as well as a 
few residential roads.

What I would like to know is: does anyone of you have a reasonable 
explanation as to how Robert66 has added his data? He has used Potlatch, 
and for that area there are no detailed Yahoo images. There is only one 
GPS trace of the main road. (It isn't mine: I'm using them only as a 
backdrop in JOSM.) I really hope he hasn't drawn the roads from memory, 
or some sketches, without the help of any GPS. Although I have traced 
only a few roads in St. Damien, I find it pretty odd that the roads I 
added myself are matching Geobase well, but the roads added by Robert66, 
are off up to 150 m!

My hands are actually itching to override his data, and only reuse the 
names, but that isn't really in the spirit of the import. I also don't 
think that would be wise, because there is no clarity about how he got 
the data. I think I'll go visit St. Damien this weekend, and do my own 
survey. If I find out that Robert66's additions are indeed way off as 
the OpenJump screenshot implies, then I'll probably replace his roads. 
I'll wait for an answer from him first. Maybe he can use a bit of 
education :)

As for my import, when I was writing this e-mail, I've uploaded the data 
from the standalone file, with bridges copied over, and some small 
corrections. See changeset 2452632. I've left out the residential roads 
in St. Damien. (Sam: there is even a note in your spreadsheet :) ) I'll 
cleanup the data, except for the St. Damien area. I'll follow a similar 
procedure for the rest of this entire area. Depending on the answer 
Robert66 can give me, I'll either leave his data in place, or add more 
Geobase roads, or eventually I'll survey those towns myself (which will 
be a lot of work).

So, what do you think? Do you have any additional suggestions as how to 
handle this situation?

Regards,

Frank

[1] 
http://www.openstreetmap.org/index.html?minlat=46.5minlon=-71maxlat=47maxlon=-70box=yeslayers=B000FTF
[2] http://osm.org/go/cKbzIEER--
[3] 
http://www.openstreetmap.org/index.html?mlat=46.625mlon=-70.75minlat=46.5minlon=-71maxlat=46.75maxlon=-70.5box=yeslayers=B000FTF
[4] http://osm.org/go/cKawVZPY--
[5] http://www.steggink.org/temp/St_Damien_QC.png
[6] http://www.openstreetmap.org/browse/way/27080076/history


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

Re: [Talk-ca] GeoBase and Canvec import tools

[Frank Steggink]

Hi Richard,

 This approach makes for many more change sets and each change set is
 likely to be a single object of some sort.  They still have to break
 these up further if the single relation is too big, but they aim for a
 changeset of about 1,000 items total.
   
Too bad that the NTS tiles usually contain more data, even in rural 
areas. But I can understand the reasoning. It keeps imports more 
manageable. Importing data is not just making sure the data gets on the 
server, but also verification, eventually clean up, making connections, etc.
 I'm finding frequent upload failures when dealing with changesets
 larger than about 16,000 nodes.  Because of the nature of these change
 sets, I can end up dropping thousands of unconnected nodes all over
 the place.  Messy.  ;-)
   
Did you use the bulkload script? I had the same issue with my very first 
import attempt last week, and cleaned up the 7000 nodes by downloading 
the changeset, adjust the XML, and upload that with JOSM.

Since that, I've used JOSM, but uploading is very slow. On average it 
takes about 1 hr to upload 8000 changes, but so far it has only hung on 
me once. That happened last Saturday. Probably there was some 
maintenance going on.
 One other approach that the French community is taking is to use
 postGIS to detect objects that overlap similar objects that already
 exist.  This is analogous to roadMatcher and it works on more object
 types, directly in the (local) database.
   
Sounds interesting. Did they mention how they would do it? When buffers 
are used for example, it is easy to exclude roads which happen to run 
parallel along existing ways... But anything better than Roadmatcher is 
actually a win ;)
 There promises to be more information coming from the French community
 and the rest of the import group in the next while.  I hope that those
 in the Canadian community, particularly those developing tools can
 consider these two approaches.
   
Keep up informing us about it :)

Regards,

Frank


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

Re: [Talk-ca] Canada Import chart

[Frank Steggink]

Hi Sam,

 I think I've done enough import for now. 9 1/4 sheet of data. The
 1/4 sheet was a section near Quebec City (021L14) with a lot of
 data and a lot of cleanup necessary.


 When you say 'sheets' im assuming you mean NTS tiles right?
Yes, that's correct. In my parlance sheets are big files, but tiles are 
small files (like the OSM tiles). Maybe sheets can be seen as large tiles ;)
 Here's where my thinking is.   We break down the process to 3 steps...
 1 - Data conversion:  by converting the geobaseNRN directly from the 
 gml file, and skip roadmatcher, and make the complete .osm files.  We 
 then make these full tiles available.
 They dont need to single tiles, you can group them how you like (just 
 keep to the grid boxes)

 2- Data copyover (rather than say 'import') as its manual.
 This way, our focus in on just getting the data available.  Local 
 people can be working on the manuall copying over of the roads that 
 they want.   So if they were the one that did the initial imagery 
 tracing, they have the option to swap or not.  and would be able to 
 attach the ref tags and relations needed.
  
 3 - Roadmatcher results.  Having these available as an .osm file, so 
 users can copy might be better than importing.
Regarding the roadmatcher results: in most cases I've modified the OSM 
files I end up with after running RoadMatcher. The reason is to correct 
obvious errors, copy bridges (which are often missing in the existing 
OSM data), and various other reasons. I'm not sure if anyone would be 
interested in those files. Since you've expressed multiple times that 
you hope that people make them available, what is the exact reason for that?

About the general process for the import: this sounds feasible to me. 
Hopefully more people would be inclined to help. I found Roadmatcher 
often very frustrating to work with, and I often end up retiring roads 
which are already in OSM, so Roadmatcher will ignore them. For the final 
result this doesn't matter, but having to do so much manual work, 
devaluates the use of Roadmatcher.
 So this way, our efforts are in the actual conversion.  At this point, 
 only 4 or 6 people in Canada know how to actually use RoadMatcher and 
 geobase2osm.  (have a GIS background) Everyone else knows how to use 
 JOSM, and can open up a .osm file and start copying over the data.   
 It's not essential that we record WHO is copying over the data, as 
 long as 1 person in each tile area is listed as a contact to figure 
 out WHO is doing the import copy.   Usually, it would be 1 person per 
 tile, but for busy areas it would be 2 or more.
I think it would also be good that after the copying (or maybe during 
the copying) the data is connected. You mentioned in the past that 
existing data shouldn't be touched, and I don't know your current stance 
(haven't followed the import discussions too closely), but eventually 
someone will link the NRN data with the old OSM data. When this is done 
during the import, it is easier to keep track of what has imported. 
Although is a lot of work to do, it is worth it in the end. In case 
you're not sure if a connection should be made, you can see in the 
original Geobase data if there is a connection.
 So far I haven't looked at CanVec data yet. It takes a while to figure 
 out how exactly it is constructed, which is hard to do with a quite 
 demanding day-job, and with only a few hours left in the evening. I 
 actually wanted to look at the NHN data first, and import some of it. 
 I think I'll contact Yan Morin for info about that. Regarding the 
 Geobase data: do you know if land cover is also available to us, and 
 if the quality is good enough to be imported? If we manage to import 
 that, we'll really be able to show off how forested Canada is :)
Apparently Richard had this idea already. It is a great addition. 
Although the data can be out-of-date, this will also happen when we add 
data of the current situation today, and review it several years from now.

In order to get it straight: only the roads come from Geobase, and the 
rest is CanVec? There is a lot of overlap in the datasets, and for a 
casual observer of these discussions they look to be the same.
 (fyi, on an aside) the contours.osm converted file and the SHP files 
 will be available in the 'extra' folder of the canvec2osm (data 
 conversion script).   I just got word about the OSM Atlas project, 
 and to get contours, the shp files are needed, to make the PDFs.
Weren't you interested in creating an atlas last year? It seems someone 
finally heard your wish, and had time to implement it :)
 Do you think i should make ALL the SHP files also available for all 
 the data (right now im deleting them, after conversion)?  So then we 
 have a origional copy of it, rather than just my converted version.   
 (since the data gets updated, the older version might not be 
 available) to make the DIFF shp file. (for what was added since last 
 time).
I don't know. I'm 

Re: [Talk-ca] NTS sheet to lat/lon converter

[Frank Steggink]

Frank Steggink wrote:
 Hi,

 Because it is not obvious to everyone what the extent of the NTS sheets 
 is, I've created a little service which converts them to lat/lon 
 coordinates. It is also possible to show them directly as a box in 
 OpenStreetMap. I'm not sure if a similar service exists (probably NRCan 
 has one), but this might also be useful for the Geobase import.

 The main entry page is at http://www.steggink.org/geo/
 At the bottom you can enter the NTS sheet number. It can be done in the 
 formats 'NNN', 'NNNL' or 'NNNLNN' where N is a number and L is a letter.

 When you press the Submit button, you'll go to a page which shows the 
 center coordinates. (No extent yet.) For example, entering '021L14' (the 
 sheet containing Quebec City) leads you to 
 http://www.steggink.org/geo/nts_area/021L14. From there you can go to 
 various services accepting coordinates, like OSM.

 When you press the OSM button in the main page, you'll directly see the 
 result as a box in OSM. The calculated URL 
 http://www.steggink.org/geo/nts_area/021L14/osmbox gets you redirected 
 (HTTP 301) to the OSM site: 
 http://www.openstreetmap.org/?minlon=-71.5minlat=46.75maxlon=-71maxlat=47box=yes

 This means that you can also use the URL at my site as a template, 
 replace the bbox, and you'll directly go to the OSM page. The next idea 
 I had would be to using these URLs at the Geobase import status page, so 
 everybody sees directly what area exactly was imported.

 If you notice any errors (especially in the polar regions, due to the 
 inconsitent box sizes), please report them to me. And yeah, this is not 
 entirely RESTful, because errors are also returned as HTTP 200 - OK :)

 Regards,

 Frank

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

   
Sorry for not escaping the URLs properly. The second one should be this: 
http://www.steggink.org/geo/nts_area/021L14. (should work with those 
brackets).

Frank

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

Re: [Talk-ca] NTS sheet to lat/lon converter

[Frank Steggink]

Sam Vekemans wrote:
 Thanks :)
 I just used your tile BBOX so then the link is in the chart.
 ...
 We always use 
 http://geogratis.gc.ca/geogratis/en/product/search.do?id=28954
 But since it's hard to get the BBOX your method is awesome :)

 What do you think of the googleDoc chart?

 I tried it for that tile you listed in there.

 What area are you in?

 Cheers,
 Sam

 Twitter: @Acrosscanada
 Facebook: http://www.facebook.com/sam.vekemans


 On Thu, Aug 20, 2009 at 7:40 PM, Frank Steggink stegg...@steggink.org 
 mailto:stegg...@steggink.org wrote:

 Frank Steggink wrote:
  Hi,
 
  Because it is not obvious to everyone what the extent of the NTS
 sheets
  is, I've created a little service which converts them to lat/lon
  coordinates. It is also possible to show them directly as a box in
  OpenStreetMap. I'm not sure if a similar service exists
 (probably NRCan
  has one), but this might also be useful for the Geobase import.
 
  The main entry page is at http://www.steggink.org/geo/
  At the bottom you can enter the NTS sheet number. It can be done
 in the
  formats 'NNN', 'NNNL' or 'NNNLNN' where N is a number and L is a
 letter.
 
  When you press the Submit button, you'll go to a page which
 shows the
  center coordinates. (No extent yet.) For example, entering
 '021L14' (the
  sheet containing Quebec City) leads you to
  http://www.steggink.org/geo/nts_area/021L14. From there you can
 go to
  various services accepting coordinates, like OSM.
 
  When you press the OSM button in the main page, you'll directly
 see the
  result as a box in OSM. The calculated URL
  http://www.steggink.org/geo/nts_area/021L14/osmbox gets you
 redirected
  (HTTP 301) to the OSM site:
 
 
 http://www.openstreetmap.org/?minlon=-71.5minlat=46.75maxlon=-71maxlat=47box=yes
 
 http://www.openstreetmap.org/?minlon=-71.5minlat=46.75maxlon=-71maxlat=47box=yes
 
  This means that you can also use the URL at my site as a template,
  replace the bbox, and you'll directly go to the OSM page. The
 next idea
  I had would be to using these URLs at the Geobase import status
 page, so
  everybody sees directly what area exactly was imported.
 
  If you notice any errors (especially in the polar regions, due
 to the
  inconsitent box sizes), please report them to me. And yeah, this
 is not
  entirely RESTful, because errors are also returned as HTTP 200 -
 OK :)
 
  Regards,
 
  Frank
 
  ___
  Talk-ca mailing list
  Talk-ca@openstreetmap.org mailto:Talk-ca@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ca
 
 
 Sorry for not escaping the URLs properly. The second one should be
 this:
 http://www.steggink.org/geo/nts_area/021L14. (should work with those
 brackets).

 Frank

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


Hi Sam,

No, I haven't looked at the Googledoc charts yet. Too busy with other 
stuff, among which mapping :) I'm living in Quebec City, that's why I 
used it as a sample.

Frank

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

Re: [Talk-ca] NTS sheet to lat/lon converter

[Frank Steggink]

Richard Weait wrote:
 On Thu, Aug 20, 2009 at 10:37 PM, Frank Stegginkstegg...@steggink.org wrote:
   
 Hi,

 Because it is not obvious to everyone what the extent of the NTS sheets
 is, I've created a little service which converts them to lat/lon
 coordinates. It is also possible to show them directly as a box in
 OpenStreetMap. I'm not sure if a similar service exists (probably NRCan
 has one), but this might also be useful for the Geobase import.
 

 Very nice Frank,

 Thank you for this.  Are you considering something like this for the extents?

 http://www.openstreetmap.org/?lat=46.875lon=-71.25zoom=10layers=B000FTFTminlon=-71.5minlat=46.75maxlon=-71maxlat=47box=yes

   
Richard,

What do you mean exactly? Combining the marker or the box? Or linking to 
the OSM box from this page, 
http://www.steggink.org/geo/nts_area/021L14? I was at least 
considering the latter (also for the other links, like KML and Google 
Map), but not tonight anymore :)

Frank

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

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

[Frank Steggink]

Hi Richard, Sam, Steve,

Thanks for your feedback. I'll continue using PostGIS (good for my own skills 
as 
well), and look at the other suggestions you've made. I'll also leave the NIDs 
on the data which I will eventually upload. They don't hurt, although there is 
the theoretical possibility that due to subsequent edits they get shifted 
(splitting and joining).

I'll also investigate PostGIS buffering a bit more. 10 to 20 meters should be 
enough. In cases of roads which have been shifted 100 meters, they need better 
investigation anyways. In case they turn out to be drawn from low-res imagery, 
they can better be replaced by the Geobase data. Hopefully the buffering won't 
cause data to be removed accidentally. For areas where the OSM density is quite 
small (as in my test areas) it is no big deal to remove duplicate Geobase roads 
manually. Better to be safe than sorry. How would RoadMatcher deal with a case 
where two roads are aligned, but one of them has been shifted?

With regard of this I also think a manual step should always take place. (Maybe 
even to evaluate discarded data.) We must only make sure that it covers those 
parts which can't be done automatically, so the required amount of time spent 
of 
it is as small as possible. Our brains can still make judgments better than the 
computer. I don't think anyone has very sophisticated algorithms which 
eliminate 
human input in the process ;)

I hope to really start with the Geobase import soon. I came across the Global 
Administrative Areas (GADM) database, which is part of the BioGeo project 
mentioned at the potential datasources. I've looked more closely at the data, 
and exchanged some ideas about the import of this data as administrative 
boundaries with the guys on #osm-nl. (Sorry, sometimes it's necessary to chat 
in 
my mother language ;)) I also inquired after use of the data by OSM, because of 
their copyright (CC-BY-NC-SA 3.0), and because they aggregated data from 
various 
other sources.

Regards,

Frank

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

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

[Frank Steggink]

Hi,

I've sent below mail to Michel, who I met at the Sherbrooke mapping party last 
year, but I presume he's quite busy, so I'm posting it here.

I haven't really been following the talk-ca mailing list, but I would like to 
give it a try. I don't know yet how much time and energy I'm willing to spend. 
That usually comes in big lapses, just like my OSM contributions :)

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

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

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

3. Is there an existing tool to cut the NRN data files in tiles? Or does 
someone 
host the NRN data which are already cut into tiles? Or is it preferred to use 
the Ibycus topo maps (and convert them to OSM)?
 a. Do the Ibycus maps contain all attributes? I don't think so, since 
they're created specifically to be used by GPSs.

4. Since it seems there are several different individual import / 
experimentation processes going on, many imports will have to be rolled back. 
(I'll create a new OSM user, so my changes will be easily detectable.) Is there 
a test server available?

[Not in the mail to Michel:]
Based on the gathered information I've developed a workflow based on PostGIS. I 
still need to test it, but if this workflow is useful, I'll share it with you. 
It will involve a certain degree of manual checks, but my experience is that 
data imports always need close attention. It is very easy to mess up things. We 
also need to take things like relationships into account.

That's about it for now. As a test area I'll probably use an area in the 
Beauce. 
Sheet 021L07 seems to be a good candidate. I've mapped most of the existing OSM 
roads, and there are some larger residential areas, but not too much.

Regards and thanks in advance,

Frank

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

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

[Frank Steggink]

Hi Steve,

Thanks for your response.

 Yes the wiki needs a cleanup, I've been hoping someone else would do it 
 since that doesn't seem to be happening I will try to find sometime soon 
 to delete all obsolete information from the wiki pages.
I'll try to do some cleanup, once I have a better understanding of th eefforts 
of others.

 Yes please try to keep nids for data that actually comes from geobase.
 Not importing could limit us in the future.
In what way would it limit us? When we'll receive a new dataset from Geobase? 
Or 
do you hint towards other datasets which are linked to the NID? In that case 
that additional data can't be linked to existing database, because that doesn't 
contain the NID attributes.

 b. How can we guarantee that the final import will be consistent? 
 (See also
 my first question.)
 
 Depends what you mean by consitent.
 1. Using consistent tags for things, the best way to ensure this is to 
 look at what others are doing and share your scripts.
 
 2. data consistency, ie roads line up and are joined between different 
 imports or between the existing and geobase data.  Right now we have no 
 automated consistency tools, we are depending on people to manually line 
 up/connect ways post import.
Both meanings were intended. I wonder if automatic consistency will work. It 
seems to have a too high chance of failure.

 You are free to use your own processes and software.  I don't think any 
 two people are doing the exact same thing for importing.  This is the 
 process I follow
 
 You don't need to use roadmatcher, you just need to have some method of 
 avoiding hundreds of duplicate roads.
I actually wanted to use PostgreSQL/PostGIS, but it seems that no OSM data can 
be exported from it. At least not when OSM data was previously imported through 
osm2pgsql. Maybe it will work to keep the Geobase data in Postgis, export as 
OSM, and then apply some postprocessing (fixing in JOSM).

 For comparision purposes what I've done with the larger areas in Alberta:
 
 1. Populate a postgis database with the NRN shapefile
 2. Populate a postgis database with the OSM data using osm2pgsql
 3. Generate a NRN and OSM shapefile for the area that I'm interested in
 using pgsql2shp and some SQL queries. I handle reprojection during this
 process as well (lately I've been reprojecting into meters)
 4. Import both shapefiles into jump and automatch with roadmatcher
 5. Export my results
 6. Run geobase2osm on the NRN GML file(yes I had to download the NRN data
 twice) and produce a standalone file
 7. Review the standalone file in JOSM
 8. Upload the standalone file with bulk_upload.pl
 9. Manual fixup in JOSM.
I'm going to try to generate buffers around the imported road data from OSM, 
and 
will use it to clip away any Geobase data (NRN) which is entirely within a 
certain distance from the OSM data. And then export it to OSM. I'll need to 
work 
it out further, using my test area. I think that a buffer of 10 or 20 meter is 
enough.

 Do not use any of the Ibycus stuff the import the licenses are not 
 compatible. Do not use ibycus in the geobase import.  Someone should 
 have removed these references from the wiki a long time ago.  I will try 
 to do it soon.
OK. Makes sense to me. It's already postprocessed to some degree, rendering it 
less suitable.

 I just viewed/posted my initial .osm files in JOSM and when people where 
 happy with them I did an import to a small isolated area.  Using a 
 seperate userid is a good idea.
 
 You can get the latest version of geobase2osm.py here, a number of 
 people have used this as the basis for their custom procedures.
 
 http://svn.openstreetmap.org/applications/utils/import/geobase2osm/geobase2osm.py
  
OK, will give that a try :) But it might be necessary if I use PostGIS as the 
main repository for the Geobase data. I want to remove the number of steps as 
much as possible, to make it more automatable and user friendly.

One final question: what is the accuracy of the Geobase data? Is it worse, 
comparable, or better than typical GPS tracks? The roads I've drawn so far 
match 
the Yahoo imagery quite well, although usually there is a slight offset of a 
few 
meters.

Regards,

Frank

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