* Select child selected, add to selection
Forgot to add type:way. So, in JOSM type in "child selected type:way",
and check the radio button Add to selection.
Frank
On 22-8-2012 17:59, Frank Steggink wrote:
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 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 idealists and realists. I see the
current state of OSM as the status quo, so I take it for granted. I
think that Canvec falls within that status quo situation as well,
otherwise the OSM data offered by NRCan would have looked
differently, after all those years of discussions and reviews.
I have invited this user to discuss the issues he found on talk-ca. I
think that would be much more constructive than having him directing
all those issues to me, since they occur far beyond his own backyard
as well...
Regards,
Frank
[1]
http://www.openstreetmap.org/?lat=46.1749&lon=-74.5535&zoom=14&layers=M
[2]
ftp://ftp2.cits.rncan.gc.ca/pub/canmatrix2/50k_tif/031/j/canmatrix2_031j02_tif.zip
_______________________________________________
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
_______________________________________________
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca