https://wiki.openstreetmap.org/wiki/Import/Guidelines
Usually involves creating a wiki page like
https://wiki.openstreetmap.org/wiki/Ottawa/Import/Plan
outlining that licensing isnt an issue and what tags would be
used(addr:housenumber and addr:street for address points) as well as
contigency
Okay, I'll scrap the idea of importing roads - mostly because they are
already there - just off skew but a dozen or more meters in many places. I
wrote software to fix most of our issues in our area - maybe there is an
API to do the same with OSM and I can volunteer some skills there.
As a side
> Imports are quite the pain to try and do - there's a whole process in place
> now to do them. It stems from the experience in the States of an import more
> than a decade ago of the TIGER data (from the Census Bureau) that is still
> being fixed after pretty large amounts of time working
Thanks Kevin, That would make sense if there were attribute changes but if
all the basics are the same they are still split. There is odd fields in
the data likely left over from an import years ago that just was never
cleaned up. With GIS databases, it would have been so easy to do a merge on
Hey Jason,
Imports are quite the pain to try and do - there's a whole process in place
now to do them. It stems from the experience in the States of an import
more than a decade ago of the TIGER data (from the Census Bureau) that is
still being fixed after pretty large amounts of time working
Hi Jason,
I am happy to help. Sounds like a fun project.
John
On Tue, Jul 7, 2020 at 1:02 PM Jason Carlson
wrote:
> While waiting for a response I think if I import roads that already exist
> (albeit incorrectly) it will possibly be just as much work to fix. I tried
> editing changes but the
While waiting for a response I think if I import roads that already exist
(albeit incorrectly) it will possibly be just as much work to fix. I tried
editing changes but the aerial photos by Bing are horribly inaccurate in
some places. I think they must pay for accuracy based on the amount of
Petit rappel pour ceux moins familiers avec les imports Canvec. Il est bon de
bien connaître la structure des données et doublons éventuels à corriger. Aussi
JOSM est très utile pour repérer les chemins en doublon et corriger.
Les développeurs OSM mentionnent régulièrement des multipolygones
I don't think canvec is updating these things on a regular basis, OSM after
corrections are usually more accurate than canvec anyways and doubt would
update data from Canvec to fix outdated data
On Tue., Jul. 7, 2020, 11:27 a.m. Hannes Röst, wrote:
> Dear Adam and Daniel
>
> Thanks a lot, so
Dear Adam and Daniel
Thanks a lot, so this answers the question that these are import artefacts and
not intended. One question still remains, namely whether we should clean them
up and how (joining ways makes sense from the OSM data model but may make a
future update based on CANVEC files
As mentioned by Daniel, this is due to the nature of the CANVEC data
import. CANVEC shapefile data is based on tiles and these will chop
practically anything into pieces - lakes are just ones of the more
noticeable. I have corrected some of these myself as I've come across
them. Just be careful
Have a look at the osm wiki page for canvec import, you will understand why.
Sent from Galaxy S7
From: Hannes Röst
Sent: Tuesday, July 7, 2020 1:02:43 AM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] NRCan lakes
Hello
I am a contributor from Toronto and I
If it becomes over 2000 nodes in a single "way" or shape, it's recommended
to make it a multipolygon. The reason NRCan does this is probably because
it's on the edge of what they call "NTS Tiles" which is a grid that
organizes the data (see forests in Canada
13 matches
Mail list logo
