Re: [Talk-ca] no preset nodes
On Sun, 7 Jun 2009, Michel Gilbert wrote: > Hi osmers, > > Is there someone in Alberta can explain what are the no preset nodes for ? > There 2 nodes at each way intersections in many cities I checked : Red Deer, > Ponoka, Wetaskiwin ... Is this part of the process to connect the way > intersections not created during the import ? > > Thanks, > > Michel I suspect that these are left over from the import where for portions of Alberta many intersections where not sharing nodes. That was fixed(as far as I know), but it is possible deleting many deletes of the unused nodes didn't go through. It should be possible to detect untagged nodes that aren't part of any way/relation that are older than a week and delete them. I think there might even be existing scripts for this. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Geobase data vs. OSM data on import
- Michel Gilbert arranged a host of electrons thusly: - > Hi Austin, > > With the experience I have doing import and road capture with my GPS I came > to the conclusion that if the data is bad I would delete it. If I were the > initial author of that road I you delete it with a complete set of new roads > I would be very happy because you bring OSM in a better project. Your opinion seems to reflect that of the rest of folks who've replied: "Use your judgement, better data is preferrable." It means I've got more work to do, but there should be less effort after-the-fact, so I don't mind re-running the exports & roadmatcher bits. I might have the data in by the end of the week, given work & life & all that jazz. > So go ahead upload and thanks to participate in OSM. Thanks for the welcome :) peace, Austin. -- Build a man fire, he'll be warm for a day. Set a man on fire, he'll be warm for the rest of his life. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] no preset nodes
Hi osmers, Is there someone in Alberta can explain what are the no preset nodes for ? There 2 nodes at each way intersections in many cities I checked : Red Deer, Ponoka, Wetaskiwin ... Is this part of the process to connect the way intersections not created during the import ? Thanks, Michel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Geobase data vs. OSM data on import
- Richard Weait arranged a host of electrons thusly: - > On Sun, 2009-06-07 at 00:09 -0700, Austin Henry wrote: > > Hi all, > > > > I'm working on importing (most of) the 082E tile, > > Kelowna, Osoyoos, Grand Forks That's the one. Penticton was my original goal, because my Dad would like to get involved in the project, and he lives there. Figured it would be nice for him to start from a place where the (for me) tedious road mapping is done, and he can concentrate on the other stuff. > > and the part of the > > import process where you match roads in RoadMatcher is taking ages, > > Odd. I've never seen RoadMatcher take more than about a minute to > conflate. Did you get any errors when opening the shape files? Oh, the conflation step takes about 30 seconds. It's the manual step after that to match the 100s of Km of highway with the geobase data that was taking a long time. Sometimes figuring out what should even be matched was difficult, because the distance between the geobase road and OSM road was up to about 80m (in a few places). > We can expect the NRN to be generally "Excellent" with scattered "meh." > They use better equipment than most of us. Road centerlines should be > right-on for when the data was taken. The road configuration my have > changed since then. There may have been a construction diversion. Or a > large tractor-trailer in the next lane may have caused a reflection that > hurt the location accuracy. That's what I figured, > Use your best judgement, you might be our only local expert for 082E. > Continue to give preference to data from OSM contributors unless you > have a good reason. Consider contacting the previous contributors to > see if they can shed some light on the discrepancies you are seeing. I had another look at some of the data in potlatch this morning, and it looks like the majority of the areas I was having troubles with were traced roughly from the low res yahoo imagery. And to the local expert... well... I used to live in Penticton, and never had my driver's license while I was there. But I'll pass it over to my dad after I've run the imports, and he's ridden his bike and driven all over the place around there. I'll pass the expert torch :) > Best regards, > Richard Thanks for your help, Austin. -- Build a man fire, he'll be warm for a day. Set a man on fire, he'll be warm for the rest of his life. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Geobase data vs. OSM data on import
On Sun, Jun 7, 2009 at 1:09 AM, Austin Henry wrote: > It looks like the data was generally collected in one drive through by a > non-local. I'm not saying the data's crap, some of is really quite > good. But there are parts of it where it looks like a helicopter was > used :) And I'm not entirely sure how trustworthy the NRN data really > is -- presumably it's good enough for the government to use, and most of > it says the positional accuracy is 25m or less... Highway 3 looks a lot like most of the Highways used to look in Alberta. The way that was laid down only very generally followed where the actual road was located. For the most part, even the low resolution Yahoo imagery could be traced by hand to give a better representation of the roads. > So, what should I do for an upload? Just upload the standalone portions > like the process says, or should I upload all of the data, and delete > the current OSM data where it's strange? I'd delete the obviously erroneous OSM data before running the roadmatcher script. Anywhere that roadmatcher thinks is close enough to be a match will get dropped. No matter how poor the existing data is, if it's close enough for roadmatcher, then that's what you get. It can take quite a bit of work to fix up the parts that got missed. If there's not much data in the area, personally, I'd run through it by hand looking for low quality data, delete it, and run the script. Data that is high quality, such as GPS traces converted to ways, or hand laid traces that follow the real roads nicely would get left in place. One issue with the GeoBase import that I have, is that every way becomes fragmented. Each portion of a road between 2 junctions is it's own unique way. This means that if you are going to be making a change to a road, you may have to make that change dozens, hundreds, or even thousands of times depending upon the length of the road, and how fragmented it is. One way of dealing with this type of situation, would be to import the GeoBase data, and use the nodes and ways as a skeleton to build upon. All roadways would end up being a relation that uses the nodes and ways to define the relation. I'm not too sure how it would work exactly though. Physical attibutes such as location would be defined by the GeoBase data, which could then be modified by OSM users if they have better or newer information. Other physical attributes such as bridges and such could probably stay on this layer as well. What about things that would encompass large stretches of the roadway, such as surface type, speed limit, number of lanes... would that stay associated with the physical layer and all of it's multitude of ways, or should that be associated with the relation? Things like road name, and number would be associated with the relation, I would think. The non-physical items, that can't be seen on the ground. What this would do, is leave the GeoBase lat/long and UUID basic data in place, but allow us to still build ways and such in a manner similar to what was done before, at least the way I used to do it. If I laid out my street in my hometown, I would draw it from end to end if possible, and then tag it with all the attributes I needed. If there was a second road that branched off of my first road, I would then add that in, and tag it. With GeoBase, my first road would end up becoming 2 separate ways with 2 UUIDs. If I wanted to change the attributes on my street, using the GeoBase data, I would have to edit both parts of my street. Using a relation to define my street as encompassing both GeoBase ways, I can still change a number of the attributes of the whole street by only editing the relation. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Geobase data vs. OSM data on import
On Sun, 7 Jun 2009, Austin Henry wrote: I encountered a bug in the roadmatcher matching where it would get confused and enter an infinite loop of sorts. I patched it to detect the looping condition and break out. The version of the code I posted on github has this fix. You can also get at a jar that works with openjump 1.3 + this change at http://www.easy-share.com/1905578997/roadmatcher-1.4.jar It might solve your problem. > Hi all, > > I'm working on importing (most of) the 082E tile, and the part of the > import process where you match roads in RoadMatcher is taking ages, even > though there's very little data in OSM for the area (the reason I picked > this tile, along with the fact that I used to live in the area). The > reason it's taking so long is the fact that the OSM data for Highway 3 > and the NRN data are very different in places. > > It seems like a combinations of things might have affected the data > that's present now: > - valleys throwing the GPS accuracy way out (or killing it entirely, and > enabling the "feature" of garmin (and other?) units where it just > interpolates until it gets a lock back); > - low sampling frequency in the saved GPX tracks, which then got > imported directly, or was traced at low zoom levels (the satellite > data for most of highway 3 is low-res); > - there are certainly other scenarios, but it's getting late and my > brain's a bit fuzzy from staring at RoadMatcher for hours. > > It looks like the data was generally collected in one drive through by a > non-local. I'm not saying the data's crap, some of is really quite > good. But there are parts of it where it looks like a helicopter was > used :) And I'm not entirely sure how trustworthy the NRN data really > is -- presumably it's good enough for the government to use, and most of > it says the positional accuracy is 25m or less... > > So, what should I do for an upload? Just upload the standalone portions > like the process says, or should I upload all of the data, and delete > the current OSM data where it's strange? > > The files for this tile are at > http://drop.io/bvhw44o#list/sort_by_name/order_by_asc/60 > for those who might wish to look at it. I can find bounding boxes for > some examples if folks wish them. > > peace, > Austin. > > -- > Build a man fire, he'll be warm for a day. > Set a man on fire, he'll be warm for the rest of his life. > > ___ > 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] Geobase data vs. OSM data on import
On Sun, 2009-06-07 at 00:09 -0700, Austin Henry wrote: > Hi all, > > I'm working on importing (most of) the 082E tile, Kelowna, Osoyoos, Grand Forks > and the part of the > import process where you match roads in RoadMatcher is taking ages, Odd. I've never seen RoadMatcher take more than about a minute to conflate. Did you get any errors when opening the shape files? > even > though there's very little data in OSM for the area (the reason I picked > this tile, along with the fact that I used to live in the area). The > reason it's taking so long is the fact that the OSM data for Highway 3 > and the NRN data are very different in places. [ ... ] > But there are parts of it where it looks like a helicopter was > used :) And I'm not entirely sure how trustworthy the NRN data really > is -- presumably it's good enough for the government to use, and most of > it says the positional accuracy is 25m or less... We can expect the NRN to be generally "Excellent" with scattered "meh." They use better equipment than most of us. Road centerlines should be right-on for when the data was taken. The road configuration my have changed since then. There may have been a construction diversion. Or a large tractor-trailer in the next lane may have caused a reflection that hurt the location accuracy. Use your best judgement, you might be our only local expert for 082E. Continue to give preference to data from OSM contributors unless you have a good reason. Consider contacting the previous contributors to see if they can shed some light on the discrepancies you are seeing. Best regards, Richard ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Geobase data vs. OSM data on import
Hi Austin, With the experience I have doing import and road capture with my GPS I came to the conclusion that if the data is bad I would delete it. If I were the initial author of that road I you delete it with a complete set of new roads I would be very happy because you bring OSM in a better project. So go ahead upload and thanks to participate in OSM. Michel 2009/6/7 Austin Henry > Hi all, > > I'm working on importing (most of) the 082E tile, and the part of the > import process where you match roads in RoadMatcher is taking ages, even > though there's very little data in OSM for the area (the reason I picked > this tile, along with the fact that I used to live in the area). The > reason it's taking so long is the fact that the OSM data for Highway 3 > and the NRN data are very different in places. > > It seems like a combinations of things might have affected the data > that's present now: > - valleys throwing the GPS accuracy way out (or killing it entirely, and > enabling the "feature" of garmin (and other?) units where it just > interpolates until it gets a lock back); > - low sampling frequency in the saved GPX tracks, which then got > imported directly, or was traced at low zoom levels (the satellite > data for most of highway 3 is low-res); > - there are certainly other scenarios, but it's getting late and my > brain's a bit fuzzy from staring at RoadMatcher for hours. > > It looks like the data was generally collected in one drive through by a > non-local. I'm not saying the data's crap, some of is really quite > good. But there are parts of it where it looks like a helicopter was > used :) And I'm not entirely sure how trustworthy the NRN data really > is -- presumably it's good enough for the government to use, and most of > it says the positional accuracy is 25m or less... > > So, what should I do for an upload? Just upload the standalone portions > like the process says, or should I upload all of the data, and delete > the current OSM data where it's strange? > > The files for this tile are at > http://drop.io/bvhw44o#list/sort_by_name/order_by_asc/60 > for those who might wish to look at it. I can find bounding boxes for > some examples if folks wish them. > > peace, >Austin. > > -- > Build a man fire, he'll be warm for a day. > Set a man on fire, he'll be warm for the rest of his life. > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca > -- Michel Gilbert ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] CanVec data now in Cranbrook, BC
Hi all,
A (kind-of) quick note,
While i am still working on the 092c area (westcoast) and uploading a sample
area. I am starting to and continuing to upload data to this Cranbrook area
tile 082g12. So that more features will be shown.
Everything accept these below have been uploaded:
HD_1470009_1single_line_watercourse_GeoBase (11.8 megs)
VE_1240009_2wooded_area (9.44megs)
HD_1480009_2waterbody_GeoBase (3.64megs)
BS_2010009_0amenity_v(2.22megs)
TR_1770009_0dead_end_GeoBase(2.05meg)
SS_1320049_2wetland(1.07megs)
FO_129_0elevation_point_GeoBase(825k)
The last few i'll probably still manually upload (just split it into a few)
I doing this one as an example, where (we) use the canvec.osm file, that
gets generated using the canvec2osm script. (Which is now MOSTLY
complete). Where users can be using the data as a "tool", rather than a
means. What this means is that while im mapping a trail, i'll be adding in
the other map features that are available around me. AND that this
information is "VARIBIABLE" because i was physically there.
What i'm doing is focusing on the less than 500k .osm files that get
created, and uploading those. For the files which are over 500k, what i do
is manually select corners and regions; copy parts of it; make a new layer;
paste that part; hide the other layer; then upload just a part of it; then
remove those uploaded features from the origional.
The only stipulation with this method, is this. IF 2 or more people are
working in the same area AND also uploading the canvec data, these people
can't be working independently (they would step on each others toes). What
they can (and should) IMO do is get together for a 'mapping party' and divvy
up the data types or regions, and import the whole area all in 1 go. (so
there is no conflict). This way, we can have full communication, as well as
learn techniques from eachother.
Process:
My bias is for Vancouver Island ('cause i live here) and can use the region
as a full test bed for the import process.
Because (right now) more folks are focused on GeoBase Roads import, this
leaves me some time. :-)
I do (IMO) think that the best approach to the import is to be following
behind on all the areas which have already been processed with geobase2osm.
Because now everyone knows that im working on this tile, PLEASE contact me
when your going to be working on it, (so i no to stop) until your done the
geobase import process).
CONGRATULATIONS:
I want to congratulate everyone on the great work so far. It seems that
everyone is using the chart, and keeping everyone upto date on whats going
on.
CanVec Status Chart:
I think that it's about time to start posting the CanVec import status. (im
now at v0.60)
Do you think we need more time to let more people examine these test areas?
Do you think we already covered most of those bugs listed?
Do people have objections to my process so far?
Here's the latest area.
(It's renders so fast WOW :)
http://www.openstreetmap.org/?lat=49.595&lon=-115.768&zoom=11&layers=B000FTF
Cheers,
Sam Vekemans
Across Canada Trails
P.S. Perhaps i shouldn't have imported the data for this area (as it's
contrary to what i said before, with just focusing on the 092c area until
it's correct). However, im confident that what i upoaded is fine. However,
im prepared to have the changesets reverted if needed.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Geobase data vs. OSM data on import
Hi all, I'm working on importing (most of) the 082E tile, and the part of the import process where you match roads in RoadMatcher is taking ages, even though there's very little data in OSM for the area (the reason I picked this tile, along with the fact that I used to live in the area). The reason it's taking so long is the fact that the OSM data for Highway 3 and the NRN data are very different in places. It seems like a combinations of things might have affected the data that's present now: - valleys throwing the GPS accuracy way out (or killing it entirely, and enabling the "feature" of garmin (and other?) units where it just interpolates until it gets a lock back); - low sampling frequency in the saved GPX tracks, which then got imported directly, or was traced at low zoom levels (the satellite data for most of highway 3 is low-res); - there are certainly other scenarios, but it's getting late and my brain's a bit fuzzy from staring at RoadMatcher for hours. It looks like the data was generally collected in one drive through by a non-local. I'm not saying the data's crap, some of is really quite good. But there are parts of it where it looks like a helicopter was used :) And I'm not entirely sure how trustworthy the NRN data really is -- presumably it's good enough for the government to use, and most of it says the positional accuracy is 25m or less... So, what should I do for an upload? Just upload the standalone portions like the process says, or should I upload all of the data, and delete the current OSM data where it's strange? The files for this tile are at http://drop.io/bvhw44o#list/sort_by_name/order_by_asc/60 for those who might wish to look at it. I can find bounding boxes for some examples if folks wish them. peace, Austin. -- Build a man fire, he'll be warm for a day. Set a man on fire, he'll be warm for the rest of his life. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
