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: [OSM-talk] Everything is a tertiary road

[Ben Discoe]

Stephan,

I can see you are correct that user "4719341" created thousands of
roads which are incorrectly tagged tertiary.  Looking at the aerial,
almost all of them should be correctly tagged "unclassified" or
"track"; very few are actual tertiaries.  They did this across almost
the entire Magway Region
(https://www.openstreetmap.org/relation/5996479/)

Of course the best thing would be to try to contact the user and get
them to fix their own tags (and of course, any future roads that they
make).  If that does not prove possible or they are unwilling, then a
possible answer to "how can this be repaired", is:

1. Load the whole Magway region into JOSM.
2. Find their work using a search (type:way user:4719341
highway:tertiary) (I did this, and found around 17,000 results)
3. Mass-change those ways to unclassified.
4. In a subsequent manual pass, correct the tagging to track (perhaps
30% of their work) and actual tertiary (perhaps 2%).

That way, only a minority of the roads would have to be manually
changed, because unclassified is correct for the majority.
Naturally, we should wait to hear from the user first.

-Ben

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

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

[OSM-talk] Nominatim and waterway relations, broken?

[Ben Discoe]

Nominatim has been able to find waterway relations for at least a
couple years, now.

For example, if you search "Klamath River", Nominatim's top result is:
https://www.openstreetmap.org/relation/3624126

Which is great.  But two days ago, I created another river:
http://www.openstreetmap.org/relation/7232264

Searching Nominatim for "Spoon River" currently gives "No results found".

Supposedly, Nominatim's database delay is small (minutes, not days).
Anyone know why it's failing to find a large, 2-day-old relation?

Thanks,
Ben

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

[OSM-talk] Is Overpass falling far behind the database?

[Ben Discoe]

Usually, using "overpass turbo" returns results which are very recent,
usually less than an hour.

https://wiki.openstreetmap.org/wiki/Platform_Status gives an Overpass
status of "OK".

However, for the past 2 days, results seem to be very out of date.

As an example, this query: http://overpass-turbo.eu/s/kfp

returns hundreds of nodes which were moved or deleted days ago.

Is it a known issue of replication delay?

Thanks,
Ben

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

[OSM-talk] OSM Stats page broken since Nov. 4?

[Ben Discoe]

As far as I can tell, the stats page
(http://www.openstreetmap.org/stats/data_stats.html) which usually
updates every day, hasn't updated since November 4.  Are people aware
of this and is there any ETA for a fix?

Thanks,
Ben

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

[OSM-talk] Local guidance for finding places (Insarro, Ethiopia..)

[Ben Discoe]

There is a popular local restaurant which says on its website, "Many
ingredients and spices are brought directly from the town of Enssaro
in Ethiopia"

Curious, I looked for this town in OpenStreetMap.  Nothing exists with
that spelling, but a similar spelling "Insarro" gives a single node
(http://www.openstreetmap.org/node/1150893606) which is apparently
just a "GeoDatabase" import (presumably GNS/GeoNames), which causes
OSM (and Google etc.) to believe there is a "locality" there.

However, there is no town there, nor even any settlements nearby.
There is a village "Lemi" to the south, and other small villages to
the north.

This raises the general question, how to find local knowledge?

The wiki page (http://wiki.openstreetmap.org/wiki/WikiProject_Ethiopia)
contains mostly dead links and points to a deserted mailing list for
Ethiopia; perhaps there is a more general East Africa, or Africa
specific OSM list or forum which actually has people?  Anyone that
would know if a town of that name actually exists, and where it might
be?

Thanks,
Ben

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

[OSM-talk] Is tile rendering having a crisis?

[Ben Discoe]

The tile renderer, "renderd", has been heavily overloaded for quite a
while, like 90% of the time it is dropping, and the dirty queue is
entirely ignored.  However, in the past day, something has happened so
that it is even more overloaded, even the standard request queue is
not getting handled, and the dropped is out of control:

http://munin.openstreetmap.org/openstreetmap/orm.openstreetmap/renderd_processed.html

Does anyone know what's going on?  This is a large frustration for me,
and I'd happily donate money to beefing up our render server(s).

Thanks,
Ben

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

Re: [OSM-talk] ford=no for highways which are known to have no fords?

[Ben Discoe]

On Tue, May 31, 2016 at 2:08 PM, Richard  wrote:
>> FWIW, I simply set the following key mapping in JOSM:
>>
>> Shift-D: add bridge=yes, layer=1
>> Shift-C: add tunnel=culvert, layer=-1
>
> nice.. but still need to select or add two nodes, split the
> ways, and select the correct segment before hitting s-d/s-c.

I agree, I always intended to add that to make it easier... so this
evening I took the time to figure it out, and it works great: You can
select a way, or multiple ways, or a way and two nodes, or just two
nodes.  I'll write up a diary post soon with my new powerful script.
:)

-Ben

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

Re: [OSM-talk] ford=no for highways which are known to have no fords?

[Ben Discoe]

FWIW, I simply set the following key mapping in JOSM:

Shift-D: add bridge=yes, layer=1
Shift-C: add tunnel=culvert, layer=-1

Making bridges/culverts is then very quick and easy.

On Tue, May 31, 2016 at 10:01 AM, Martin Koppenhoefer
 wrote:
>
> 2016-05-31 15:03 GMT+02:00 Richard :
>>
>> often enough I get messages from people saying that drawing a bridge
>> or culvert for every minor highway/waterway crossing causes more
>> trouble than use and I tend to agree.
>
>
>
> I disagree. Either there is a bridge / culvert in reality, and in this case
> why wouldn't we want it in OSM, or there isn't and then it is a simple error
> waiting to be corrected.
> Which trouble do these elements cause?

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

Re: [OSM-talk] Upload slowness - what's going on?

[Ben Discoe]

API download and upload has gotten fast(er) tonight, for the first
time since the server move on May 9!
Whatever they've done today, it's working!
I am so happy. This really impacts my life.
Thanks,
Ben

On Fri, May 13, 2016 at 5:59 AM, Grant Slater
<openstreet...@firefishy.com> wrote:
> Hi All,
>
> On Monday 9th May 2016 the master OSM database server was moved to
> York (Bytemark) from London (Imperial).
> This was to avoid multiple upcoming weekends of planned power testing
> & maintenance at the Imperial data centre. For the last few years
> Imperial has housed all our main critical systems including master &
> slave DB servers and frontend & backend web/api servers. We also added
> 4 new frontend/backend web/api server to York on Monday.
>
> We now have the master database server in York and the secondary
> database server in Imperial. We also have a warm standby slave db in
> AWS Ireland. A fourth SSD (NVMe) based DB server was delivered
> yesterday (Thursday), but it needs testing (burn-in, reliability,
> performance etc) before we can start using it. Slave DB servers can be
> promoted to master if required.
>
> The slave db servers serve Web/API read traffic and writes go to the
> master. When the frontend + backend servers were in the same data
> centre as the master db server the latency was <1ms. We now run a VPN
> to connect the servers up and the latency is ~8ms Imperial to
> Bytemark. Currently we are using the frontend & backends server at
> Imperial (closest to slave db read server) and sending writes over the
> VPN to Bytemark. The extra 8ms roundtrip is triggered multiple times
> based on the size of the upload changeset, this is the root cause for
> the slower uploads. The link between Imperial & Bytemark can handle
> gigabit speeds. Over the last few days we've been tweaking the VPN
> settings to get optimal latency & throughput over the links.
>
> Over today (for at least the weekend) we are switching to the new
> frontend & backend servers in York (Bytemark). London Imperial will be
> offline from approximately 5pm (GMT+1) for the first weekend of power
> maintenance.
>
> In summary: The slow uploads are a known issue and we'll fix as soon
> as practical. Our main concern has been setting up multiple data
> center redundancy to avoid extended downtime.
>
> Here is the list of all core hardware and hosting locations:
> https://hardware.openstreetmap.org/
>
> Hope that answers the questions. ;-)
>
> Photos or it didn't happen:
> * Syncing & powering down before we start London -> York DB move:
> https://twitter.com/OSM_Tech/status/729582996685213696
> * Staged photo of racking up the master DB server at Bytemark:
> https://twitter.com/OSM_Tech/status/729693392737832961
> * Testing the new Frontend / Backend servers a week ago:
> https://twitter.com/OSM_Tech/status/728286193696292865
>
> Bytemark are a fantastic hosting company and their ongoing support of
> the OpenStreetMap project is highly commendable. Please support them
> ;-) https://twitter.com/bytemark/status/729698435339853824
>
> Kind regards,
>
> Grant
> Part of the OSM Ops team.
>
>
> On 13 May 2016 at 11:44, Tim Waters <chippy2...@gmail.com> wrote:
>> I believe the Dev mailing list may have some of your technical answers
>> https://lists.openstreetmap.org/pipermail/dev/2016-May/thread.html
>>
>> It appears from that list that the database servers are now a few
>> hundreds of miles from where the web servers are, causing the increase
>> in latency. I do not know if this is a permanent change, the thread on
>> osm-dev does seem to indicate that things are still in flux.
>>
>> Tim
>>
>>
>>
>> On 13 May 2016 at 06:02, Ben Discoe <bdis...@gmail.com> wrote:
>>> Several of us have noticed radically slowly upload speed for
>>> changesets, roughly since the server move on May 9.  Like, as
>>> painfully slow as it used to be, it's now several times slower.
>>>
>>> It's been discussed with @OSM_Tech on twitter, in this thread:
>>> https://twitter.com/OSM_Tech/status/730857486618664960
>>>
>>> Before I get too hysterical, can somebody tell me what happened, and
>>> can it be fixed?
>>>
>>> OSM_Tech's mysterious message:
>>>   "Large uploads will take around 3 times longer. Small uploads extra
>>> delay should be minimal."
>>>
>>> Does this mean that something did change?  It is database writes that
>>> are taking so much longer?  Changesets with as few as 400 object are
>>> taking several times longer, what constitutes "large" vs. "s

[OSM-talk] Upload slowness - what's going on?

[Ben Discoe]

Several of us have noticed radically slowly upload speed for
changesets, roughly since the server move on May 9.  Like, as
painfully slow as it used to be, it's now several times slower.

It's been discussed with @OSM_Tech on twitter, in this thread:
https://twitter.com/OSM_Tech/status/730857486618664960

Before I get too hysterical, can somebody tell me what happened, and
can it be fixed?

OSM_Tech's mysterious message:
  "Large uploads will take around 3 times longer. Small uploads extra
delay should be minimal."

Does this mean that something did change?  It is database writes that
are taking so much longer?  Changesets with as few as 400 object are
taking several times longer, what constitutes "large" vs. "small"?
Can it be fixed?  Can I donate large sums of money somewhere to help
it get fixed?

Thanks,
Ben

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

Re: [OSM-talk] Gamification in Volunteered Geographic Information in regard with Contributors' Motivations

[Ben Discoe]

I thought it was odd that the survey listed two osm "gamifications" I'd
never heard of, and didn't mention a few I do know of, like the missingmaps
leaderboard ( http://www.missingmaps.org/leaderboards/#/missingmaps ), the
telenav challenges (2014-2015, with leaderboard and cash prizes) or
numerous other leaderboards like MapLesotho's (
http://maplesotho.cbroderick.me ), not to mention the OSM rank itself, as
it appears on HDYC ( http://hdyc.neis-one.org/ ) which I check daily. HDYC
shows that there are still two human accounts higher-ranked than me,
obviously I must map harder!! :)

-Ben
On May 4, 2016 10:56 AM, "Chen Chen"  wrote:

Hello,



My name is Chen Chen and I am a Masters student working under the
supervision of Dr. Peter Johnson in the Department of Geography and
Environmental Management at the University of Waterloo. We are currently
seeking volunteers from the OpenStreetMap (OSM) community to participate in
a study that focuses on the impact of game elements on motivations to
contribute to OSM. We would like to invite you to join our study.

Participation in this study involves a web questionnaire, with a potential
follow-up interview. The link to the web questionnaire is:
https://www.surveymonkey.com/r/osmvgigamification. The questionnaire
should take
approximately 20 minutes of your time. This study has been reviewed and
received ethics clearance through a University of Waterloo Research Ethics
Committee.



In appreciation of the time you have given to this study, you can enter
your email address into a draw for a $50 Amazon Gift Card. Your odds of
winning the prize is based on the number of individuals who participate in
the study. The final decision about participation is yours.



Sincerely,



Chen Chen



M.Sc. Geomatics

Geospatial Innovation Laboratory

Department of Geography and Environmental Management

University of Waterloo

c226c...@uwaterloo.ca

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

Re: [OSM-talk] [Talk-us] Slack

[Ben Discoe]

On Tue, Mar 29, 2016 at 1:02 PM, Michael Reichert  wrote:
>> I find this a really worthwhile conversation to have. IRC is still great for 
>> some but it’s hardly inclusive.
>
> Is http://irc.openstreetmap.org/ no web interface?

I have tried (every year for the past ~20 years) to get IRC to work.
I never have seen it work, and I am a tech-savvy person.

There is always _something_ that prevents IRC from working.

For example, I tried that link you provided, I press "Login", and it
just spins endlessly, saying "Waiting for irc.openstreetmap.org..."
Could it be a corporate firewall issue? Or is the server down? Why is
there no timeout?  Who knows, it is that user-unfriendly.

> might lack some advertisment (and maybe an modern styling).

It lacks the ability to let people connect.  IRC is a non-starter.

-Ben

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

[OSM-talk] Status page down?

[Ben Discoe]

I haven't been able to reach
http://www.openstreetmap.org/stats/data_stats.html for the past 17
hours.   Does the link work for others, or is there an ETA for it to come back?
Thanks,
Ben

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

Re: [OSM-talk] Status page down?

[Ben Discoe]

FWIW, it's now 2:15 AM UTC (past the time it usually updates) and
there's still no status page at
http://www.openstreetmap.org/stats/data_stats.html
Perhaps the bug is still there?

On Tue, Dec 8, 2015 at 10:00 AM, Tom Hughes <t...@compton.nu> wrote:
> On 08/12/15 17:45, Ben Discoe wrote:
>
>> I haven't been able to reach
>> http://www.openstreetmap.org/stats/data_stats.html for the past 17
>> hours.   Does the link work for others, or is there an ETA for it to come
>> back?
>
>
> It wasn't generated last night due to a bug, it will be back tonight.
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/

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

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