Re: [Talk-GB] building shapes from OS Street View

2010-04-10 Thread Steve Doerr
From: Robert Scott li...@humanleg.org.uk

 That's great! I can stop reading about Harris operators. I totally agree 
 about orthogonal snapping.

Orthogonal snapping would be useful more generally - do any of the editors 
have this feature for manually drawn buildings etc.?

-- 
Steve 



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


Re: [Talk-GB] building shapes from OS Street View

2010-04-10 Thread Glenn Proctor
On Sat, Apr 10, 2010 at 9:23 AM, Steve Doerr
steve.do...@blueyonder.co.uk wrote:

 Orthogonal snapping would be useful more generally - do any of the editors
 have this feature for manually drawn buildings etc.?

JOSM has an Orthogonalise shape option which is very useful for buildings.

Glenn.

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


Re: [Talk-GB] OS StreetView accuracy: caution!

2010-04-10 Thread Dave Stubbs
On Fri, Apr 9, 2010 at 7:00 PM, Kevin Peat ke...@kevinpeat.com wrote:

 On 9 April 2010 18:40, Robert Scott li...@humanleg.org.uk wrote:


 Hasn't one of OSM's (many) mantras been doesn't matter if it's
 approximate: someone can always improve it later or rough is better than
 nothing? Sure, some of the OS data is rough, but it is better than nothing,
 and quite good for a first pass.

 +1 on this.

 It seems odd to me that we are encouraging people to contribute using often
 pretty rubbish mobile phone gps receivers but complaining that the OS data
 is not sub-metre accurate.

I think the point is not to assume that where OSSV and OSM disagree,
that OSSV is necessarily the correct one. It might generally be, but
if you can't go out and check, be very careful what you do.

If it's just how curvy it is I generally find checking the OSM GPS
traces is a good idea, because you often find the GPS trace just
hasn't been followed very well.


 Maybe some people will be put off if the empty areas are filled in with OS
 data so they don't have a blank canvas but I bet there are just as many
 people out there not knowing where to start who would add street names and
 POIs and clean-up any OS errors.

That's a very good summary.
By far the most important thing is not to leave a mess.


Dave

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


Re: [Talk-GB] Separation of sources

2010-04-10 Thread Ed Avis
Simon Ward si...@... writes:

I’d just like to see something where ground surveyed data is the
ultimate, and it’s not clear to me that it is the ultimate now.

I've done a fair bit of ground surveying, but all of it has been from the
starting point of an existing map - usually one traced from the aerial imagery.
If the street layout appears slightly wrong I won't usually correct it, because
the GPS precision is not good enough in heavily built-up areas.  (Only if there
is an obvious tracing mistake or a missing street will I use the GPS data to
make changes to geometry.)  So what we have at the moment, in the UK at least,
is already a mishmash of photographs, ground survey, and (in rural areas) 
tracing
from older OS maps.  A pure survey-only OSM has not existed except in the very
early days before Yahoo photos.

If what you mean is that in the event of a disagreement, the only way to check
map data is to look on the ground, then of course this has always been true.
I don't think importing from any other source changes that.

Do remember that the OS maps have also been produced largely by ground survey,
and their surveyors are no less skilled or dedicated than our OSM volunteers.

-- 
Ed Avis e...@waniasset.com


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


Re: [Talk-GB] building shapes from OS Street View

2010-04-10 Thread Dave Stubbs
 It's worth noting that the Yahoo aerial photography is also out of date; in 
 some
 cases [1] people have traced streets from the photo which bear no relation to
 what's on the ground.  Yet nobody suggests we should stop tracing from it.

Yes they do.
http://lists.openstreetmap.org/pipermail/talk/2007-September/017830.html

I've slightly changed my mind since then, but anyway.

Dave

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


Re: [Talk-GB] building shapes from OS Street View

2010-04-10 Thread Ed Loach
Glenn wrote:

 JOSM has an Orthogonalise shape option which is very useful
 for buildings.

And a terracer plugin which I find useful for converting traced
buildings to semi-detached* (or however many) properties.

Ed

* Slight issue when the width of the two semi-detached houses
together is less than their depth as it then splits the rectangle on
the wrong axis, but this seems fairly rare around here (and I now
know how to rotate objects in JOSM as a result).



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


[Talk-GB] building shapes from OS Street View

2010-04-10 Thread TimSC
Hi again, thanks for the comments.
 How well would this scale up to the whole country? (!! Not automatically 
 importing the results of course !!) I'm thinking about tile/batch sizes, tile 
 boundary issues, 
I was thinking about using a sliding window approach, by loading in an 
extra margin from surrounding tiles, selection pixels by colour, create 
edge fragments as before. But in this case, the step that creating 
polygons should only use the central region of the image for the 
starting point of the polygon. This should avoid any buildings getting 
cut in half at the tile edge.

 any necessity for porting parts to c++ for speed etc.
   
Converting edge fragments to polygons is the slow step at the moment - 
about 15 minutes a tile. I am using the approach describe in the link 
below. Fortunately, I know a bit of Boost.Python and C++ if we need the 
speed. I suspect a better algorithm in python could improve the speed 
issue rather than resorting to C++.

http://losingfight.com/blog/2007/08/28/how-to-implement-a-magic-wand-tool/

I am also seeing the limitations of my approach. Problems arise from the 
lack of image resolution and the anti-aliasing of the colours in the 
image. Since I am using a binary classification by colour for selecting 
pixels, it tends to result in rounded corners (due to the colour 
blending into the backgound). The polygon simplification then has to 
descriminate between a rounded corner due to anti-aliasing and corner 
which is real. Given the resolution, a straight edge might only be 2 or 
3 pixels long, and a rounded corner has a radius of about... 2 or 3 
pixels. But then, these building shapes are also a total nightmare to 
manually survey. Example attached (you will probably need to zoom in):

http://timsc.dev.openstreetmap.org/dev/hard-building-shapes.png

I have some ideas for a better algorithm (based on active contour 
models), but that is pretty complex. I will give that some thought. 
Basically, we need to segment the shape but not by simply binary 
selecting pixels inside or outside the shape (and it can try to be 
orthogonal, if possible). The code I have does provide a good 
initialisation of the model, so it is hardly wasted effort. If anyone 
has any better ideas, you can have a copy of my python code to try things.

Regards,

TimSC


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


Re: [Talk-GB] building shapes from OS Street View

2010-04-10 Thread Robert Scott
On Saturday 10 April 2010, TimSC wrote:
 Converting edge fragments to polygons is the slow step at the moment - 
 about 15 minutes a tile. I am using the approach describe in the link 
 below. Fortunately, I know a bit of Boost.Python and C++ if we need the 
 speed. I suspect a better algorithm in python could improve the speed 
 issue rather than resorting to C++.

If needs be, and other algorithms fall short, the advantages c++ has are things 
like ability to optimize for cache behaviour, ability to choose algorithms for 
your data structures (such as lists) which I imagine are getting hammered by 
your approach. A last resort though.

 
 http://losingfight.com/blog/2007/08/28/how-to-implement-a-magic-wand-tool/
 
 I am also seeing the limitations of my approach. Problems arise from the 
 lack of image resolution and the anti-aliasing of the colours in the 
 image. Since I am using a binary classification by colour for selecting 
 pixels, it tends to result in rounded corners (due to the colour 
 blending into the backgound). The polygon simplification then has to 
 descriminate between a rounded corner due to anti-aliasing and corner 
 which is real. Given the resolution, a straight edge might only be 2 or 
 3 pixels long, and a rounded corner has a radius of about... 2 or 3 
 pixels. But then, these building shapes are also a total nightmare to 
 manually survey. Example attached (you will probably need to zoom in):

Indeed. The approach I was going to take was taking the buildings as 
anti-aliased grayscale ( which I guess I would have to be generated by tuning a 
few heuristics about which indexed colours to pick ) and use a corner finding 
algorithm on them. I was hoping to be able to get sub-pixel accuracy with this 
approach (corner detectors are perfectly capable of it with grayscale data), 
but I still have a few papers to read.

I was thinking momentarily of a hybrid approach, using detected corners to more 
precisely position nodes.

As far as the orthogonalizer idea goes, I think a simple refinement would need 
to be made - orthogonalization threshold would need to be inversely 
proportional to segment lengths. Lengths that are short relative to pixel size 
will have more quantization errors than long segments.

 I have some ideas for a better algorithm (based on active contour 
 models), but that is pretty complex. I will give that some thought. 
 Basically, we need to segment the shape but not by simply binary 
 selecting pixels inside or outside the shape (and it can try to be 
 orthogonal, if possible). The code I have does provide a good 
 initialisation of the model, so it is hardly wasted effort. If anyone 
 has any better ideas, you can have a copy of my python code to try things.

You've done a lot better than me - I'm still at the 'reading papers' stage ;)


robert.

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


Re: [Talk-GB] Nonsense edits in Durham London - revert required

2010-04-10 Thread Gregory
Well spotted ddixon, some of those edits seem like clear he he, you can
change wikipedia to say what you like edits. There have just been some
accidental deletes in Canada and it seems like the way to deal with them is
manually.

 To undelete a way, press u, wait 5–10 seconds for the deleted ways to
 load, select the way to undelete, and press k. To revert a way to an
 earlier version, select the feature, press k, choose the version, and
 click Revert.

 From the Potlatch documentation:
 *  undelete will always use the most recent version of each
 constituent node (even if it's moved)
 *  revert will use the historic version of each constituent node, but
 if that node is still visible and has moved somewhere else, it will
 generate a new node ID


My mouse is far to sensitive in clicking (I think I need to clean it) to
deal with Potlatch easily. Can you manage to put everything back?

Please post the mailing list how the users respond.
If there is no response and there are more edits (or your corrections get
put back) then a block is likely needed, which can be done through OSM
Foundation people (or at least they know who does it). Hopefully once the
stuff is put back then the users will either contribute responsibly or move
on to troll elsewhere.

On 7 April 2010 10:54, David Dixon da...@ddixon.force9.co.uk wrote:

 User Ajbites has made a number of obviously nonsensical edits this
 afternoon, mainly in Durham but also 1 in Haiti and 1 in London.  I have
 sent a polite welcome, but please don't email.  Could someone with the
 required knowledge please revert these edits?  One slight complication
 is that another very new user (bashiboy2) has already re-edited some of
 these ways.  These edits appear mainly neutral but the closeness in
 timing suggests the two users are connected - there doesn't appear to be
 any new useful data here either so if necessary these edits can be
 reverted too.
 Thank you,
 David

 Ajbites:
 http://www.openstreetmap.org/browse/changeset/4354930
 http://www.openstreetmap.org/browse/changeset/4354906
 http://www.openstreetmap.org/browse/changeset/4354900
 http://www.openstreetmap.org/browse/changeset/4354888
 http://www.openstreetmap.org/browse/changeset/4354864
 http://www.openstreetmap.org/browse/changeset/4354839
 http://www.openstreetmap.org/browse/changeset/4354783
 http://www.openstreetmap.org/browse/changeset/4354745
 http://www.openstreetmap.org/browse/changeset/4354677

 bashiboy2:
 http://www.openstreetmap.org/browse/changeset/4354863
 http://www.openstreetmap.org/browse/changeset/4354856
 http://www.openstreetmap.org/browse/changeset/4354818
 http://www.openstreetmap.org/browse/changeset/4354793

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




-- 
Gregory
o...@livingwithdragons.com
http://www.livingwithdragons.com
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] OS StreetView accuracy: caution!

2010-04-10 Thread Dave F.
Tim François wrote:
 I think OS *is* more accurate on the whole, 
I think you're probably correct, but the problem arises when we *assume* 
that it's more accurate in areas where we're not  knowledgeable of 
what's on the ground.

That's not to say we shouldn't map, but I think we should, as we've been 
doing before, tag in caveats using the fixme or notes tag to say we're 
uncertain of certain areas.

Cheers
Dave F.

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


Re: [Talk-GB] VectorMap District: Completely crazy idea, maybe, but...

2010-04-10 Thread Dave F.
Mike Harris wrote:
  The lack of public right of way information is disappointing - but it 
 is within OSM's capabilities to walk and map it. However, the lack of 
 field boundary information is a serious deficiency as these are 
 invaluable in practice to walkers attempting to plan, navigate, record 
 and publish walks - especially in the more lowland and more farmed 
 areas. Without the OS's right to enter onto private land without any 
 advance permission, OSM mappers will remain seriously hampered in any 
 attempt to map field boundaries. Hedges may be visible in good quality 
 satellite or aerial photography but fences (and especially electric 
 fences) will be very difficult.

I agree field boundaries are valuable for walkers, but only those 
abutting or near PROWS are relevant  these are obviously obtainable by 
walking there. Spring is in the air, put your boots on a go walking!

Cheers
Dave F.

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