Re: [Talk-us] problematic import in san francisco state university

[Paul Norman]

On 6/18/2016 10:13 AM, Eric Ladner wrote:

I could fix it manually, if you like.  Pretty straight forward, actually.


I wouldn't suggest putting too much work into it until we determine a 
source, since it's possible the data might have to go.


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

Re: [Talk-us] problematic import in san francisco state university

[Eric Ladner]

well, by overlapping, I mean there's two trees in the exact same spot with
the exact same details on them (but one is a has some more ultra-detailed
fields like height, diameter, etc).  Looks like it might have been an
attempt to add more detail to the tree, but a previous load wasn't cleared
out properly.

Not sure what to do with the height, diameter since I think it's in feet
for the height and inches for the diameter (where OSM has tags for height
in meters and circumference in meters)

On Sat, Jun 18, 2016 at 9:11 PM Kevin Kenny  wrote:

> Great! Well done!
>
> I admit that I haven't looked at the aerial photos too closely, but
> overlapping trees aren't ordinarily of great concern to me. Tree
> canopies overlap in nature, after all.
>
> On Sat, Jun 18, 2016 at 8:03 PM, Eric Ladner 
> wrote:
> > Cleaned up about 40,000 - 50,000 points.  Removed about 95% of the
> co-linear
> > points.  Fixed some of the pitches and most of the tagging.  There are
> still
> > about 100 overlapping trees with some odd tagging that haven't been
> cleaned
> > up yet, though.
> >
> > On the good side, you can download the whole university in one request in
> > JOSM without OSM complaining about the request being too big.
> >
> > On Sat, Jun 18, 2016 at 12:13 PM Eric Ladner 
> wrote:
> >>
> >> I could fix it manually, if you like.  Pretty straight forward,
> actually.
> >>
> >> On Fri, Jun 17, 2016 at 4:22 AM Rihards  wrote:
> >>>
> >>> see https://www.openstreetmap.org/way/338699618/history and other
> things
> >>> around there.
> >>>
> >>> looks like a ~ 1 year old import. doesn't seem to have followed the
> >>> guidelines at all, has things like Shape_Area, Shape_Leng,
> >>> landcover=Forest, a lot of excess nodes in straight segments.
> >>>
> >>> irc is suggesting a revert, but i'm afraid to make an even bigger mess
> -
> >>> would be nice if some locals could pick that one up.
> >>>
> >>> (granted, it looks nice in the renderer... but that's about it :/ )
> >>> --
> >>>   Rihards
> >>>
> >>> ___
> >>> 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
> >
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] problematic import in san francisco state university

[Eric Ladner]

Cleaned up about 40,000 - 50,000 points.  Removed about 95% of the
co-linear points.  Fixed some of the pitches and most of the tagging.
There are still about 100 overlapping trees with some odd tagging that
haven't been cleaned up yet, though.

On the good side, you can download the whole university in one request in
JOSM without OSM complaining about the request being too big.

On Sat, Jun 18, 2016 at 12:13 PM Eric Ladner  wrote:

> I could fix it manually, if you like.  Pretty straight forward, actually.
>
> On Fri, Jun 17, 2016 at 4:22 AM Rihards  wrote:
>
>> see https://www.openstreetmap.org/way/338699618/history and other things
>> around there.
>>
>> looks like a ~ 1 year old import. doesn't seem to have followed the
>> guidelines at all, has things like Shape_Area, Shape_Leng,
>> landcover=Forest, a lot of excess nodes in straight segments.
>>
>> irc is suggesting a revert, but i'm afraid to make an even bigger mess -
>> would be nice if some locals could pick that one up.
>>
>> (granted, it looks nice in the renderer... but that's about it :/ )
>> --
>>   Rihards
>>
>> ___
>> 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] Is USBR 11 in Maryland complete/correct in OSM?

[Kerry Irons]

Recognize that the small sign is not a USBR sign.  In your first link I could 
find no bike route sign unless it is that sign way off in the distance that I 
can’t make out.

 

 

Kerry Irons

 

From: Elliott Plack [mailto:elliott.pl...@gmail.com] 
Sent: Saturday, June 18, 2016 3:03 PM
To: Kerry Irons ; OSM Volunteer stevea 

Cc: FTA/Ethan ; Wade ; Phil! Gold 
; talk-us@openstreetmap.org
Subject: Re: Is USBR 11 in Maryland complete/correct in OSM?

 

I've been out there a few times taking Mapillary photos along the route so you 
can see some of the bike signage. 
http://www.mapillary.com/map/im/3Aq9dVh3Av7K_di9KKUudQ/photo 

 

This tiny one is my favorite. It's so small compared to the massive BGS: 
http://www.mapillary.com/map/im/8I80lkxdGCOgfsOCKDyYSg/photo

 

On Mon, May 2, 2016 at 7:58 AM Kerry Irons  > wrote:

Just to echo Steve’s comment on signs: encouraged but not required.  Currently 
just under 18% of the USBRS is signed.  Budget is the issue, both at the state 
and local (non state highway) level.

 

 

Kerry

 

From: OSM Volunteer stevea [mailto:stevea...@softworkers.com 
 ] 
Sent: Sunday, May 1, 2016 8:26 PM
To: Elliott Plack  >
Cc: Kerry Irons  >; 
FTA/Ethan  >; Wade 
 >; Phil! Gold 
 >; talk-us@openstreetmap.org 
 
Subject: Re: Is USBR 11 in Maryland complete/correct in OSM?

 

Elliott Plack  > wrote:

 

Update on this. I was out along the AT in the Weverton area and had a chance to 
observe this unique condition where cyclists are encouraged to use what is 
effectively a motorway for travel.

 

I always found my armchair mapping of this highly suspect and so I added 
copious tags that it still needed additional editing.  >1.5 years later, 
Elliott submits nice, solid work after a field trip.  Well, all right!

 

There is no sign or specific indication of USBR 11 anywhere out there that I 
observed. What I did see was that the eastbound carriageway of US 340 had a 
green sign indicating that it was a bicycle route between the Keep Tryst Rd / 
Valley Rd intersection, and Exit 2, which had a sign indicating the bicycles 
must exit. The "Bike Route" signs did not have a number reference. There is a 
Bike Route sign on the exit to MD 67 as well, which is the part that is USBR 11.

 

Kerry might remind everybody that signage is optional (I would say “encouraged” 
but I don’t think that is official) on the USBRS.  The route exists by state 
DOT declaration and “acceptance” into the national (non) network (called USBRS) 
by AASHTO.  Signs cost money and effort to erect:  sometimes there is budget to 
do so and the state DOT finds a way to erect signs, sometimes signage is a more 
grass-roots effort (fundraising, sign-raising…) than it is state (DOT) 
sanctioned or funded.  A Bike Route sign is a legal, MUTCD-acceptable way to 
sign here but I think we all agree the M1-9 sign (USBR 11) would be preferred.

 

For the sections of US 340 where cyclists are allowed, I added the 
cycleway:right=shoulder tag. I also fixed any FIXMEs related to this condition.

 

Thank you, thank you.

 

Curiously, the eastbound carriageway is tagged as trunk, while the westbound is 
tagged motorway. While there is a single grade intersection along the eastbound 
portion (at Keep Tryst Rd), I think that this is probably not enough to call 
the entire section trunk. Thoughts on that?

 

You did the field trip!  The whole area around Keep Tryst Road and how it 
interfaces with AT and bicycles is complicated, and now seems much better 
tagged.

 

Finally, I also improved the routing of USBR 11 where it crosses the Potomac 
River on a shared-use rail bridge. There is a staircase to access the bridge 
that I added the steps tag too. I am not sure how bicycling routers, like OSRM 
or Strava will handle steps, but cyclists are allowed there provided they 
dismount (per signage).

 

There is also a lcm (local cycleway network) around here with a staircase, it 
is near the Santa Cruz Boardwalk at the mouth of the San Lorenzo River.  These 
things can get complicated, but I believe with the proper tagging of 
bicycle=dismount (to walk up or down stairs carrying your bicycle) that a 
router should be able to figure that out.  Especially if is part of a 
lcn/rcn/ncn.  Still, I wouldn’t mind a bicycle router showing “special” 
semiotics here (yellow or hatching or something like that).

 

I have mapped my observations with this changeset: 

Re: [Talk-us] Is USBR 11 in Maryland complete/correct in OSM?

[OSM Volunteer stevea]

On Jun 18, 2016, at 12:03 PM, Elliott Plack  wrote:
> I've been out there a few times taking Mapillary photos along the route so 
> you can see some of the bike signage. 
> http://www.mapillary.com/map/im/3Aq9dVh3Av7K_di9KKUudQ/photo 

Thanks for doing this!  (Ah, rural Maryland, so pretty).

> This tiny one is my favorite. It's so small compared to the massive BGS: 
> http://www.mapillary.com/map/im/8I80lkxdGCOgfsOCKDyYSg/photo

Wow!  Where is my magnifying glass?!  Even being right ON TOP of this, I’ve 
never seen a “Bike Must Exit” sign this small!

SteveA
California
(who used to have an apartment in Baltimore at 31st & St. Paul back in the 
early 1990s)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Is USBR 11 in Maryland complete/correct in OSM?

[Elliott Plack]

I've been out there a few times taking Mapillary photos along the route so
you can see some of the bike signage.
http://www.mapillary.com/map/im/3Aq9dVh3Av7K_di9KKUudQ/photo

This tiny one is my favorite. It's so small compared to the massive BGS:
http://www.mapillary.com/map/im/8I80lkxdGCOgfsOCKDyYSg/photo

On Mon, May 2, 2016 at 7:58 AM Kerry Irons  wrote:

> Just to echo Steve’s comment on signs: encouraged but not required.
> Currently just under 18% of the USBRS is signed.  Budget is the issue, both
> at the state and local (non state highway) level.
>
>
>
>
>
> Kerry
>
>
>
> *From:* OSM Volunteer stevea [mailto:stevea...@softworkers.com]
> *Sent:* Sunday, May 1, 2016 8:26 PM
> *To:* Elliott Plack 
> *Cc:* Kerry Irons ; FTA/Ethan <
> eman...@hotmail.com>; Wade ; Phil! Gold <
> phi...@pobox.com>; talk-us@openstreetmap.org
> *Subject:* Re: Is USBR 11 in Maryland complete/correct in OSM?
>
>
>
> Elliott Plack  wrote:
>
>
>
> Update on this. I was out along the AT in the Weverton area and had a
> chance to observe this unique condition where cyclists are encouraged to
> use what is effectively a motorway for travel.
>
>
>
> I always found my armchair mapping of this highly suspect and so I added
> copious tags that it still needed additional editing.  >1.5 years later,
> Elliott submits nice, solid work after a field trip.  Well, all right!
>
>
>
> There is no sign or specific indication of USBR 11 anywhere out there that
> I observed. What I did see was that the eastbound carriageway of US 340 had
> a green sign indicating that it was a bicycle route between the Keep Tryst
> Rd / Valley Rd intersection, and Exit 2, which had a sign indicating the
> bicycles must exit. The "Bike Route" signs did not have a number reference.
> There is a Bike Route sign on the exit to MD 67 as well, which is the part
> that is USBR 11.
>
>
>
> Kerry might remind everybody that signage is optional (I would say
> “encouraged” but I don’t think that is official) on the USBRS.  The route
> exists by state DOT declaration and “acceptance” into the national (non)
> network (called USBRS) by AASHTO.  Signs cost money and effort to erect:
>  sometimes there is budget to do so and the state DOT finds a way to erect
> signs, sometimes signage is a more grass-roots effort (fundraising,
> sign-raising…) than it is state (DOT) sanctioned or funded.  A Bike Route
> sign is a legal, MUTCD-acceptable way to sign here but I think we all agree
> the M1-9 sign (USBR 11) would be preferred.
>
>
>
> For the sections of US 340 where cyclists are allowed, I added the
> cycleway:right=shoulder tag. I also fixed any FIXMEs related to this
> condition.
>
>
>
> Thank you, thank you.
>
>
>
> Curiously, the eastbound carriageway is tagged as trunk, while the
> westbound is tagged motorway. While there is a single grade intersection
> along the eastbound portion (at Keep Tryst Rd), I think that this is
> probably not enough to call the entire section trunk. Thoughts on that?
>
>
>
> You did the field trip!  The whole area around Keep Tryst Road and how it
> interfaces with AT and bicycles is complicated, and now seems much better
> tagged.
>
>
>
> Finally, I also improved the routing of USBR 11 where it crosses the
> Potomac River on a shared-use rail bridge. There is a staircase to access
> the bridge that I added the steps tag too. I am not sure how bicycling
> routers, like OSRM or Strava will handle steps, but cyclists are allowed
> there provided they dismount (per signage).
>
>
>
> There is also a lcm (local cycleway network) around here with a staircase,
> it is near the Santa Cruz Boardwalk at the mouth of the San Lorenzo River.
> These things can get complicated, but I believe with the proper tagging of
> bicycle=dismount (to walk up or down stairs carrying your bicycle) that a
> router should be able to figure that out.  Especially if is part of a
> lcn/rcn/ncn.  Still, I wouldn’t mind a bicycle router showing “special”
> semiotics here (yellow or hatching or something like that).
>
>
>
> I have mapped my observations with this changeset:
> http://www.openstreetmap.org/changeset/39027403
>
>
>
> Deeply appreciated.  This tagging and routing were a little sticky here,
> and now are much better.
>
>
>
> SteveA
>
> California
>
> USBRS WikiProject coordinator
>
-- 
Elliott Plack
http://elliottplack.me
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] problematic import in san francisco state university

[Eric Ladner]

I could fix it manually, if you like.  Pretty straight forward, actually.

On Fri, Jun 17, 2016 at 4:22 AM Rihards  wrote:

> see https://www.openstreetmap.org/way/338699618/history and other things
> around there.
>
> looks like a ~ 1 year old import. doesn't seem to have followed the
> guidelines at all, has things like Shape_Area, Shape_Leng,
> landcover=Forest, a lot of excess nodes in straight segments.
>
> irc is suggesting a revert, but i'm afraid to make an even bigger mess -
> would be nice if some locals could pick that one up.
>
> (granted, it looks nice in the renderer... but that's about it :/ )
> --
>   Rihards
>
> ___
> 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] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

Retrying because a previous attempt bounced:

On 06/18/2016 12:26 AM, Russ Nelson wrote:
>
> Kevin Kenny writes:
>   > The rule for coalescing would be to group by facility number, so all
>   > the parcels of Burnt-Rossman Hills State Forest would be one relation,
>   > while the ones of adjacent Mallet Pond State Forest would be another.
>
> How's that going to work where people (e.g. me) have made changes to
> the multipolygon? E.g. https://www.openstreetmap.org/way/32036186
> where I didn't want to duplicate the "landuse=forest" as I was adding
> landuse= or natural= to its borders?

I'm looking at that relation, and I really don't understand what
you're trying to accomplish - although when I run it through my
script, the script at least detects the tagging as something that
requires manual inspection. When I got to that parcel, I'd surely be
writing to you, asking what you meant by it! I suspect there's
something badly wrong with my understanding of multipolygons.

When I look at the multipolygon relation, I see no tags, which makes
its purpose difficult to understand. What is the meaning of a
multipolygon without tags? It's a piece of land, about which no
information is given.

The tagging for the state forest is all on the outer ring, which,
according to what I had previously understood, means that it applies
to the entire interior of the area, including the inner ring. I don't
think that's right, but you're local and I'm not. I haven't been there
in the field to see the posters and survey blazes, but the current
version of the NYS DEC Lands file shows a parcel with an inholding. I
assume that you intended by your tagging to assert that the DEC Lands
file is obsolete and incorrect and the inner parcel is actually part
of the state forest? If so, I defer to your local knowledge.

The inholding is tagged with 'natural=wood', which would make its
interior 'natural=wood' AND part of the state forest. That's
reasonable, I suppose. landuse=forest doesn't necessarily imply tree
cover (a piece could, for instance, be incompletely regrown from a
clearcut). I'm trying to avoid reigniting the whole 'forest
controversy' - we have land use ("this area is managed for the
production of timber"); land cover ("this area is covered by trees");
and cadastre ("this land is designated as 'state forest', and as such
is protected from sale or development and open to the public for
recreation when logging is not in progress"). The current tagging
structure doesn't distinguish the concepts well, but I see that as
something I just have to live with and tag as best I can. natural=wood
or landcover=trees appear to be the best tags for land cover,
landuse=forest an appropriate tag for a producing forest, and
boundary=protected_area to describe the status of protection and
public access,

So the semantics appear to be that the entire outer ring is the state
forest, there's an inner area that's a wood (as well as being part of
the state forest), and there's a multipolygon of unknown purpose
joining the two.

The way that I've handled parcels with holes in the past - and what
ogr2osm generates - is a structure where the tagging for the parcel is
on the relation, likehttps://www.openstreetmap.org/relation/6304902.
Mapnik certainly appears to understand that situation, as do QGIS and
JOSM. The 'protected area' shading appears on the correct side of the
lines, both inner and outer. In this specific case I've not specified
land use or land cover on the inner rings - I've not been to those
specific sub-areas in the field and don't know what they are. I have
been to the reservoir and can confirm that there s one private
inholding on the north shore that's posted. And there's no tagging on
the outer ring, because I had no common features that I wanted to
specify between the enclosed area and the holes. There's at least once
case in the Catskills where one of the inholdings in a "hole" in a
Wild Forest is a NYC recreation area, and the proposed fixup describes
that situation accurately.

So, if I were conflating your changes with mine, and making what looks
to me like a reasonable assumption, I'd put all the tagging for the
state forest parcel on the relation that you directed me to, have no
tags on the outer ring, and retain the natural=wood on the inner ring.
If the multipolygon and all holes shared some attribute in common, I
might promote that to the outer ring, but I try to avoid that, because
it's brittle - someone changing the attributes of the outer way may
not realize that the inner way will be affected.

But this is one parcel where if I couldn't reach you, I'd likely just
put the reimport in abeyance because I don't just overwrite the work
of mappers willy-nilly.

If I've erred on the way parcels with holes are handled, I need to
know ASAP because I'll need to revert or repair the NYCDEP import.
There were a bunch of holey parcels in that data set. In that case,
I'll also want to involve the developers of ogr2osm, because