Re: [Talk-us] buggy buildings in Maryland

[Ben Discoe]

+1 to Elliot Plack's proposal to use Simplify to remove the redundant
nodes from the poor quality imported buildings.

In fact, I did this myself for another massive import: User "jumbanho"
imported buildings for the large city of Raleigh, NC back in January
2010.
There were lots of degenerate nodes, which I cleaned up in batches
using JOSM's simplify.  I did most of the cleanup in 2015.

-Ben
On Mon, Aug 20, 2018 at 5:30 AM Elliott Plack  wrote:
>
> Here's a potential fix: use the SimplifyArea JOSM Plugin. 
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/SimplifyArea
>
> The plugin is built for fixing over-noded and buggy imports.
>
> As a test, I downloaded the plugin and then downloaded some of Annapolis 
> sailor's buildings.
>
> This building should only contain four nodes: 
> https://www.openstreetmap.org/way/525751797
>
> This building should only contain eight nodes: 
> https://www.openstreetmap.org/way/526209538
>
> The plugin successfully reduced the nodes for both buildings without 
> affecting the shape, unlike the simplify way tool.
>
> I tested it on a larger swath of 500 buildings and it took less than a second 
> to run.
>
> I haven't uploaded any of the changes yet, but I think this would be a good 
> path forward.
>
> On Thu, Aug 16, 2018 at 8:02 PM Frederik Ramm  wrote:
>>
>> Hi,
>>
>> On 08/16/2018 08:08 PM, Elliott Plack wrote:
>> > I'd say go ahead and remove the extraneous nodes
>>
>> This has now been done.
>>
>> > and also any buildings
>> > that are either version 0 or do not have any new tags (like names or
>> > addresses)
>>
>> It appears that of the 177,151 buildings still there, only 29,513 have
>> tags other than building=*. In most cases, these other tags are
>> addr:street and addr:housenumber.
>>
>> I'll let this rest for a bit to give others a chance to chime in.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>
> --
> Elliott Plack
> http://elliottplack.me
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] hydrology Alaska

[Ben Discoe]

+1 to what AlaskaDave said.

As far as I can tell in this case, the jaggies are a result of running
ScanAerial on imagery of a low resolution (i.e. zoomed out).  At that
level (LandSat resolution), a smooth lake edge looks like a jagged set
of individual pixels, where each pixel is 28 meters across.  Turning
each LandSat pixel into a vector edge produces these unattractive,
stair-setpped, inefficient polygons.

Please don't do that.

I don't know ScanAerial well, but it seems to me that you could run it
on a higher resolution (the Bing database/API has much better than
LandSat resolution here, if you zoom in).  The resulting polygons
would then need to run through a Simplify, to remove excessive detail,
before they could be uploaded to OSM.  That should result in
appropriate number of nodes, e.g. that smooth top edge of lake.

Anton, I can produce illustrations, if you need more help to understand.

If ScanAerial cannot be configured that way, then it's simply the
wrong tool to use for this situation.

On Tue, Oct 17, 2017 at 2:52 PM, Dave Swarthout  wrote:
> The tracing for that pond ( https://www.openstreetmap.org/way/532622119) is
> horrible IMO. This is the sort of geometry that drives me crazy when I look
> at Alaskan coastlines. The long zig-zag at the top edge could be better done
> with a few points and the adjoining ponds at the SE are very rough
> approximations at best. I don't know what method you used to draw that pond
> but please don't add any more that look like that one.
>
> I have done extensive work in Alaska and I appreciate your intent to add
> more Alaskan water bodies to OSM but please find another way to add them.
> There are thousands of tiny ponds dotting the permafrost in northern Alaska.
> Using your tracing technique will add hundreds of thousands of points, many
> of them useless.
>
> Dave
> (AlaskaDave)
>
> On Tue, Oct 17, 2017 at 8:01 AM, ANT Berezhnyi 
> wrote:
>>
>> (sorry for my english)
>>
>> question:
>>
>> On 2017-10-16 02:33:13 UTC velmyshanovnyi
>>
>> http://www.hdyc.neis-one.org/?velmyshanovnyi
>>
>> wrote:
>>
>> ===
>>
>> so on the question ...
>>
>> Is it possible to vectorize the USGS on the OSM if there is no Landsat,
>> and everything else in the clouds, or in the snow, or the quality is bad ...
>>
>> Hello velmyshanovnyi , There are a number of questions here. One is "is it
>> possible to vectorize the USGS". Another is "is it a good idea to do so".
>>
>> I'd suggest that you discuss what is the best source of imagery in this
>> region with other mappers, such as "imagico" who commented on
>> https://www.openstreetmap.org/changeset/52947504 . It may be that you need
>> to use several sources and combine them manually because none of them are
>> perfect. Also I would suggest asking on the talk-us and talk-ca mailing
>> lists for advice.
>>
>> With regard to "is this a good idea" other mappers think it is not. You
>> need to persuade them that it is. You need to explain what your process is.
>> Your comment on https://www.openstreetmap.org/changeset/52947504 that says
>> "Im fixed my soft" suggests that you might be performing some kind of
>> mechanical edit. If so, you need to follow
>> https://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy , which requires
>> you to discuss what you are proposing to do with other mappers before
>> actually doing it.
>>
>> Best Regards,
>>
>> Andy Townsend, on behalf of OSM's Data Working Group.
>> https://www.openstreetmap.org/user/SomeoneElse
>>
>> 
>> My sample island/hydrology (JOSM+digitalglobe-premium+bing) not import,
>> not bot :
>>
>> https://mc.bbbike.org/mc/?lon=-164.973165=60.843461=13=2=digitalglobe-premium=mapnik=hike_bike=ol_osm-no-labels=35
>>
>> after simplifacation (v2) :
>>
>> https://www.openstreetmap.org/changeset/52809320#map=16/60.8221/-164.9684=H
>> (before see v1)
>> 
>>
>> IF:
>> if there is a need to correct some hydrology somewhere - welcome 
>>
>>
>> --
>> ++ =
>> ++ ANT (Anton Berezhnyi)
>> ++ =
>> ++ E-mail   : velmyshanov...@gmail.com
>> ++ Hangouts : velmyshanov...@gmail.com
>> ++ Telegram : @velmyshanovnyi
>> ++ Skype: velmyshanovnyi
>> ++ Viber: +380939946993
>> ++ Cell : +380939946993
>> ++ https://plus.google.com/+ANTBerezhnyi
>> ++ https://profiles.google.com/velmyshanovnyi
>> ++ https://linkedin.com/in/velmyshanovnyi
>> ++ https://facebook.com/velmyshanovnyi
>> ++ https://twitter.com/velmyshanovnyi
>> ++ =
>> ++ жNtTя, яК і iTNernЕТ,
>> ++ нAЖалb, ТЕж к0лИСь
>> ++ KіH4аЄтьCя..
>> ++ =
>>
>>
>> ___
>> Talk-us mailing list
>> 

Re: [Talk-us] Low-quality NHD imports

[Ben Discoe]

I've probably done the most NHD cleanup so far (at least some degree
of fixing on the entire state of NC, most of IL, northern MI, parts of
OK/TX/UT/CO, and a lot of CA), many hundreds of hours of manual work.

Just to chime in with agreement on what everyone has said, yes to:
1. NHD has lots of issues
2. a lot of it could have been imported better
3. there are some NHD tags (like 'nhd:com_id') which are of little use
and just get in the way
4. a lot is badly out of date
5. a lot is badly overnoded (like a perfectly straight ditch using 200
noisy nodes)
6. some is badly tagged (like waterway=canal for ditches in the western USA)
7. it's still very valuable and in some places, of surprising quality
and completeness

I never just remove useless tags for the sake of removing.  They only
get touched as part of manual cleanup, which goes through a lot of
steps.

I really should write a Diary post on the steps I go through to clean
up NHD (part of these steps I already covered in
http://www.openstreetmap.org/user/bdiscoe/diary/37421)

1. Select all the waterways ("type:way AND (natural=water OR
natural=wetland OR waterway OR (child natural=water) OR (child
natural=wetland) OR (child waterway)) AND allindownloadedarea ")
2. Use JOSM validator fix-it, which will solve topology problems like
dupe vertices.
3. If the region is badly overnoded, simplify to an appropriate value
(like 80cm), then follow up with a manual cleanup/alignment.
4. Check the "waterway ends without a connection" warnings; some can
be manually fixed
5. For at least major crossings, add the bridges and culverts (I just
JOSM scripts I wrote to make this faster, but it's still very manual,
one at a time)
6. For major features that are out of date (like streams or wetlands
that were destroyed and are now shopping malls), delete or re-align
them.
7. Look over the data and fix anything else that looks very wrong

So, to answer Frederik's original question, "Is there any systematic
(or even sporadic) effort of cleaning up these old imports?"

Answer: Yes.  In addition to all the people doing great work in their
local areas, there is me.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Something very bad happening in Maryland?

[Ben Discoe]

If you look across a large area of the Maryland, for example around here:
https://www.openstreetmap.org/#map=19/39.11882/-76.62031

You may notice a few very odd things.

1. Back in 2015, user 'gdoyle' created a large number of buildings,
using small, incorrect geometry.

2. This week, user 'annapolissailor' has been doing a massive building
import in the same area.  This time the geometry is detailed, however:

  A. The changesets (such as
https://www.openstreetmap.org/changeset/52962696#map=14/39.1152/-76.6224)
say the source is "Bing", when they are clearly not Bing.  Presumably
they are some official GIS building footprints, but of unknown origin.

  B. The changeset comment says "Huge number of validation fixes and
merges", when the actual change is adding thousands of nodes (not
fixes, not merges, not validation)

  C. Thousands of these buildings are being uploaded incorrectly with
ONLY their nodes, not ways.

I left a comment on one of the changesets asking 'annapolissailor'
what they are doing, but maybe somebody here already knows?

Thanks,
Ben

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Tagging National Forests

[Ben Discoe]

Just to chime in..
As someone who has worked on protected areas in OSM globally, it has
always been obvious that the landuse tags and the boundary tags
serve clear and different purposes.
US National Forests are boundaries around land which contain many
uses(*), and landuse=forest is only one of the uses.
If i find that any area is marked as landuse=forest when it does not
actually contain all forest, i fix it, re-mapping the areas which
actually contain forest as landuse=forest (or natural=wood, as
appropriate).
Often, this is very labor-intensive.  I have done this across many
national parks globally, e.g. Ethiopia, Panama and India.

-Ben

(*) In fact, Land of Many Uses is an official slogan found on most
national forest signs. e.g.
http://www.nps.gov/features/yell/slidefile/graphics/signs/Images/16880.jpg

On Tue, Aug 18, 2015 at 11:38 AM, Mike Thompson miketh...@gmail.com wrote:


 On Tue, Aug 18, 2015 at 11:34 AM, Brian May b...@mapwise.com wrote:


 Also I think its been mentioned the boundary should be tagged as
 boundary=protected_area which handles the overall mission of national
 forests is to conserve our forests. However, the issue comes up that there
 are different levels of conservation ranging from untouched wilderness to
 actively managed areas, e.g. sustainable forestry, so a blanket
 boundary=protected_area may not be appropriate. Is there another tag that
 covers a more mixed bag? Is a new tag needed?

 As you point out, the level of protection varies. For example the Indian
 Peaks Wilderness Area overlaps with the Roosevelt National Forest [1].
 Wilderness Areas are IUCN 1b category protected areas [2] while US National
 Forests as a whole are IUCN VI protected areas [2][3]. In addition,
 regulations, and thus levels of protection, vary from place to place within
 National Forests that are not part of Wilderness Areas.   For example target
 shooting is prohibited in a number of areas within the Roosevelt National
 Forest, but is allowed in other areas.[4] National Forests are an
 administrative area only.  They are protected, but the protection level
 varies. Tagging National Forests as protected areas is acceptable as I said
 before (but not ideal as I think more about it) in my opinion because an
 authoritative source, the US Government, says National Forests are
 categorized as IUCN Category VI protected areas [3]. If we tag them as
 protected areas, we will have overlapping protected areas (e.g. National
 Forests and Wilderness Areas) and data consumers will have to select the
 highest level of protection. Ideally there would be an administrative
 boundary tag that could be used for National Forests and protected areas
 would be tagged separately.

 Not to complicate matters, but this same issue of administration vs
 protected areas applies to US (and perhaps other) National Parks.  For
 example, there are Wilderness areas within National Parks[5], as well as
 Research National Areas [6] which I believe are IUCN 1a protected areas.

 Mike

 [1] http://www.fs.usda.gov/recarea/arp/recarea/?recid=80803
 [2] https://en.wikipedia.org/wiki/IUCN_protected_area_categories
 [3] https://en.wikipedia.org/wiki/United_States_National_Forest
 [4] http://www.fs.usda.gov/detail/arp/recreation/?cid=STELPRD3836311
 [5] http://www.wilderness.net/NationalParkService
 [6] https://en.wikipedia.org/wiki/Research_Natural_Area



 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us