Re: [Talk-us] Google earth, Google maps

[Eric Ladner]

Yeah, be careful with Google Maps.  It's owned and created by a company and
if you copy from it and they can prove it, they could sue the OSM
Foundation into oblivion.  They used to even have their OWN satellites to
obtain imagery.  That's serious money.

Typically, with local edits, I put "Local knowledge" as the source.  Sounds
more highbrow than "my eyeballs".  IMO, if somebody is challenging one of
your local edits, if they are not local also, they should be told as much
and sent on their way - UNLESS it's something that relates to a mapping
standard or best practice.  Then, learn from your mistakes and move on.

On Sat, Jun 13, 2020 at 9:32 AM 80hnhtv4agou--- via Talk-us <
talk-us@openstreetmap.org> wrote:

> this was a tool on the map that measured distance.
>
>
>
> Saturday, June 13, 2020 9:29 AM -05:00 from Mateusz Konieczny via Talk-us <
> talk-us@openstreetmap.org>:
>
> You are not allowed to use Google Maps as source.
>
> Have you used Google Maps to edit OSM?
>
> "since all the maps on OSM are old news like in my local area 7 months
> old."
>
> FYI, world is larger than your local area.
>
>
> Jun 13, 2020, 16:08 by talk-us@openstreetmap.org:
>
> If you people want me to prove my edit by adding a source, and a person
> from the data group as an editor,
>
> asks me to prove it, and i redo my edit and he does not get back to me,
> why are you telling me I can not use
>
> google as a map source, since all the maps on OSM are old news. like in my
> local area 7 months old.
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org <http:///compose?To=talk%2...@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

Re: [Talk-us] Trunk VS primary,

[Eric Ladner]

I personally dislike "trunk".  Its definition is vague and leaves a lot to
interpretation (and argument).  It doesn't really add anything to the
information on the map, IMO.  A US Highway is a US Highway regardless of
how much traffic it carries or how many stoplights it has.

Maybe if the definition of "trunk" was solidified to something more
specific, it would have a more valuable use case.

On Thu, Dec 19, 2019 at 5:15 AM Mike N  wrote:

> On 12/17/2019 10:19 PM, Evin Fairchild wrote:
> > some US routes are more important than others and lumping them all as
> > primary doesn???t make any sense;
>
> The arguments here about relative importance of parallel routes makes
> sense.
>
>Some massive changes such as in
> https://www.openstreetmap.org/changeset/78620805 are raising roads which
> have no other major choices, but are apparently just because they are
> the most important.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

Re: [Talk-us] Fwd: Trunk versus motorway

[Eric Ladner]

That may be more of a note to motorists that "hey.. this freeway is coming
to an end" rather than an absolute marker of "this freeway ends here at
this sign".

San Diego's own GIS system has it marked as I-8 all the way up to where it
splits into motorway links at Nimitz/Sunset Cliffs.

Arguing about where the motorway ends and a trunk/something else begins
before an at-grade intersection is just splitting hairs.   IMO, it's a
motorway all the way up to the intersection.  If you were standing with
your back to the intersection looking down the motorway, there'd be nothing
visible that would convince you it's not a motorway.

On Wed, Nov 28, 2018 at 10:11 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> In California some roads have signs that say “End Freeway”, about 1/2 mile
> before the first intersection, eg I-8 in San Diego.
> On Thu, Nov 29, 2018 at 1:04 PM Evin Fairchild 
> wrote:
>
>> Nobody is saying that we should tag as motorways a road with a surface
>> intersection. I don't understand what it is that we're saying that's
>> causing you to come to that conclusion. We are simply saying that the
>> first surface intersection that a road comes across is where the motorway
>> should change to trunk.
>>
>> -Evin
>>
>> On Nov 28, 2018 7:42 PM, "Paul Johnson"  wrote:
>>
>> On Wed, Nov 28, 2018 at 9:36 PM Nathan Mills  wrote:
>>
>>> Unless there have been significant changes since I moved away, it should
>>> be tagged motorway between the IDL and the light at Apache/Gilcrease
>>> Extension. Before the Gilcrease was extended west of US-75, the Tisdale
>>> should have been tagged entirely as motorway. Adding the intersection did
>>> not change the character of the road south of the Gilcrease extension or
>>> the rights of adjacent landowners, so I don't see any particular reason to
>>> reclassify that segment.
>>>
>>
>> Right, but where are we getting that motorways have surface intersections
>> now?
>> ___
>> 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
>


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

Re: [Talk-us] admin_level=8 boundaries in Parker County, TX

[Eric Ladner]

Both of those are different from the boundaries in TX GIS systems (mainly
TxDOT).  The T-17 is closer than the ancient Tiger, but still slightly
different.

http://gis-txdot.opendata.arcgis.com/datasets/09cd5b6811c54857bd3856b5549e34f0_0?geometry=-97.702%2C32.666%2C-97.619%2C32.721=map-maximize

On Mon, Jul 9, 2018 at 1:36 PM Martijn van Exel  wrote:

> Frederik,
>
> These boundaries are often very outdated. I don't know which TIGER vintage
> they were imported from. I have been replacing them piecemeal from current
> TIGER as I work, but we should probably replace them altogether and have a
> plan to keep them updated. I don't think they interfere with other features
> much, but obviously that should be researched.
>
> As for this specific case, current boundary from TIGER 2017 in brown, OSM
> in green: https://cloud.rtijn.org/s/bpxPffp6ycm8rF7
>
> --
>   Martijn van Exel
>   m...@rtijn.org
>
> On Mon, Jul 9, 2018, at 05:10, Frederik Ramm wrote:
> > Hi,
> >
> > I've recently traced a little bit of stuff in Annetta, TX. The area I
> > looked at had a lot of potential for someone interested in mapping from
> > aerial imagery (houses, tracks, driveways, parking missing; some
> > driveways tagged as highway=residential etc.) and I did what I could in
> > the small area I worked on, but there was one thing I didn't dare touch
> > and that's admin boundaries. The ones I encountered often cut straight
> > through residential buildings and I thought that can't be right, but I
> > know too little about boundaries in the US to fix any of it. I am
> > specifically talking of
> >
> > https://www.openstreetmap.org/relation/114418
> >
> > and
> >
> > https://www.openstreetmap.org/way/33245202
> >
> > - maybe someone local wants to give them a closer look. Maybe it's ok
> > the way it is. The Annetta North boundary is relatively straight but has
> > one wobbly bit, is there maybe a waterway missing in OSM?
> >
> > 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
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

Re: [Talk-us] Best practice in Lane Editing 3

[Eric Ladner]

yeah, I agree..  just prodding thought.

On Thu, Jul 13, 2017 at 3:21 PM Tod Fitch <t...@fitchdesign.com> wrote:

> At least one routing app I have been using seems to use the turn:lane
> tagging [1] convention shown on the wiki. That allows the route guidance to
> let you know you should be getting into the turn lane at an appropriate
> time. Not sure if the change:lanes [2] tagging is being followed but it
> does allow for showing that crossing the solid line is not legal. Between
> turn:lanes and change:lanes, I don’t see the need to have a separate way
> that doesn’t really exist.
>
> [1] https://wiki.openstreetmap.org/wiki/Key:turn
> [2] https://wiki.openstreetmap.org/wiki/Proposed_features/change
>
>
> On Jul 13, 2017, at 1:14 PM, Eric Ladner <eric.lad...@gmail.com> wrote:
>
> Just to play Devil's advocate:  B is probably more TECHNICALLY correct
> since a solid white line indicates "lane change discouraged, but not
> illegal" and you'd probably want the routing software to indicate where the
> turn lane starts, not 200 feet later (esp. in heavy traffic and the lane's
> already full of cars).
>
> Whether it's practical to map it like that or not is another matter.
>
> On Thu, Jul 13, 2017 at 9:40 AM Tod Fitch <t...@fitchdesign.com> wrote:
>
>> Case 1: First example is much closer to how I would tag it based on the
>> the rule that it should not be a separate way if it is only separated by
>> paint.
>>
>> Case 2: I would not expect the two paths to be considered safe or legal
>> where I live in the US (not in Michigan). While there is some effort at
>> coordinating traffic laws between states, ultimately it is up to the state
>> to define their own rules so it might vary from state to state.
>>
>> On Jul 13, 2017, at 12:15 AM, Horea Meleg <horea.me...@telenav.com>
>> wrote:
>>
>> Hello all,
>>
>> Me and my Telenav colleagues are editing lane numbers in Detroit area. We
>> have two cases, where any opinion would be appreciated.
>>
>> *Case 1 *
>>
>> We are editing lanes and turn lanes and we came across with those 2
>> situations:
>>
>>1. 42.4479327, -83.0484338
>>
>> 
>>
>>1. 42.2826283, -83.3683861
>>
>>
>>
>>
>>
>> *Which road geometry do you think is correct edited? The links are edited
>> different even that, according to Bing aerial imagery they should be edited
>> in the same way. Also, in these situations, each road geometry causes a
>> different lane and turn lane tagging. *
>>
>> *Case 2*
>>
>> We have this situation:
>>
>> 42.6515832, -83.1619915
>>
>> 
>>
>>
>>
>> *According to US driving rules, are those turns allowed? Are you allowed
>> to go on the link if you are coming from South?*
>>
>>
>>
>> Thank you,
>>
>> Horea
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Help needed, Babcock Ranch near Fort Myers, FL

[Eric Ladner]

On Mon, May 15, 2017 at 2:59 AM Frederik Ramm  wrote:

> Hi,
>
>
> Maybe someone in the area fancies a fact-finding mission ;)
>
>
Some of it actually shows up in the Charlotte county GIS system[1] (the
stuff south of Lake Timber), and construction on the round-a-bout is
visible on other *cough*Google[2]*cough* satellite imagery (just below Lake
Babcock).  Construction on the now deleted roads to the left of Lake
Babcock is also visible (as of Feb imagery).

Most likely it's not vandalism or somebody using OSM for urban fantasy but
some very early county GIS or planning data that was uploaded.  It likely
should have been tagged at least as "proposed," though.  Some of it is at
least a solid "construction" now.

The imagery availble in JOSM via Bing looks pixel-for-pixel identical to
imagery available elsewhere from 2010.

[1] http://agis.charlottecountyfl.gov/ccgis/
[2] https://www.google.com/maps/@26.7872318,-81.7380132,2180m/data=!3m1!1e3

Bye
> Frederik
>

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

Re: [Talk-us] Is this a bad import or an experiment?

[Eric Ladner]

On Thu, Mar 23, 2017 at 9:25 AM andrzej zaborowski 
wrote:

Hi,

Unfortunately it looks like someone has started deleting the areas you
found, I looked at a random neighborhood and they were still visible
in the tiles but the map data shows only the small ones, now
unconnected to anything as the bigger ones are missing.  Haven't
looked at the edits history.


Nobody objected so I'm going through the area and removing the small
driveway areas and replacing larger ones with service roads and/or parking
areas as appropriate.



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

Re: [Talk-us] Available Building Footprints

[Eric Ladner]

Not to poo-poo somebody giving to OSM, but the quality of that data isn't
much better than hand drawn (and by "hand drawn" I mean with a mouse and
drawing lines only without using the building tool or the extrude
function).  Non-orthogonal lines, self-intersecting ways, non-simplified
ways, overlapping ways (vs using multipolygons) and the "Height" tag is
capitalized when it shouldn't be.

It beats nothing, though.  I'd think most large cities on that list would
have a GIS department and already have building outlines available (or
maybe through a request) and, as a bonus, address information.

And as far as the Mississippi dataset goes, it says its "Pensacola" (which
is in Florida) but is actually parts of Biloxi and Gulfport.

I'll definitely conflate the heights with the existing buildings in the
area, though.

On Wed, Mar 22, 2017 at 1:07 PM Clifford Snow 
wrote:

> Brad,
> Thanks for correcting the link.
>
> Clifford
>
> Sent from my Android phone.
>
> On Mar 22, 2017 9:59 AM, "Brad Neuhauser" 
> wrote:
>
> I think this is it?
> http://wiki.openstreetmap.org/wiki/Available_Building_Footprints
>
> On Wed, Mar 22, 2017 at 11:54 AM, Rihards  wrote:
>
> On 2017.03.22. 18:37, Clifford Snow wrote:
> > I am happy to announce that Microsoft has made available approximately
> > 9.8 million building footprints including building heights in key
> > metropolitan areas. These footprints are licensed ODbL to allow
> > importing into OSM. These footprints where manually created using high
> > resolution imagery. The data contains no funny field names such as
> > tiger:cfcc or gnis:featureid or fcode=46003, just building height.
> >
> >
> > Please remember to follow the import guidelines.
> >
> > The wiki [1] has more information on these footprints as well as links
> > to download.
>
> the link seems to be a copypaste mistake :)
>
> > [1] http://www.openstreetmap.org/user/dieterdreist/diary/40727
> >
> > Enjoy,
> > Clifford Snow
> >
> >
> > --
> > @osm_seattle
> > osm_seattle.snowandsnow.us 
> > OpenStreetMap: Maps with a human touch
> >
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
>
>
> --
>  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] Is this a bad import or an experiment?

[Eric Ladner]

On Wed, Mar 22, 2017 at 1:07 PM Mike N  wrote:

> On 3/22/2017 2:02 PM, Kevin Kenny wrote:
> > Are small driveways offensive, or is it just the polygonal ones that
> > don't connect to anything?
>
> To me, it's just the disconnected polygons.   Small driveways don't hurt
> anything, and can only provide information such as telling self-driving
> cars which driveway to pull into.
>

Really, any "highway=*" drawn as an outline rather than a center line is a
problem.   Routers and other processing code expects to follow the way
segments, not honor its area as somewhere you can drive.

I have no problem with driveways that are drawn as linear ways and connect
to things.  Personally, I don't draw short driveways in a neighborhood
where the driveway is like 30 or 40 feet long, but do where there's
something odd going on (house is very far back from the road or some other
situation where it's not obvious how to get to some building).

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

Re: [Talk-us] Is this a bad import or an experiment?

[Eric Ladner]

I can clean it up (manually), if everybody agrees.
  * remove small polygonal driveways
  * convert larger polygonal highways to actual highways where appropriate

On Wed, Mar 22, 2017 at 9:27 AM Tod Fitch <t...@fitchdesign.com> wrote:

>
> On Mar 22, 2017, at 4:59 AM, Ian Dees <ian.d...@gmail.com> wrote:
>
>
>
> On Mar 22, 2017 7:49 AM, "Paul Johnson" <ba...@ursamundi.org> wrote:
>
> On Wed, Mar 22, 2017 at 6:33 AM, Eric Ladner <eric.lad...@gmail.com>
> wrote:
>
> http://www.openstreetmap.org/#map=17/33.74152/-116.29677
>
> So much wrongness..  I don't even know where to start in describing it.
>
>
>  This really "feels" like a botched import that has the potential to
> become something actually good.  I've reached out.
> http://www.openstreetmap.org/changeset/38292137
>
>
> I noticed this yesterday when working on broken relations... It doesn't
> look like an import (mostly because they used iD and the digitization looks
> like hand drawn iD) but the tagging doesn't look right. I'd say it's a
> mapping project (they called it a "draw party") with good intentions but
> that might need some tagging cleanup.
>
>
> At least the stuff I first notice looking at that in JOSM (highway=* drawn
> as polygons without an area tag and also including a landuse=residential)
> are from single commits from a mapper that was active for several months a
> few years ago. Change set claims source is Bing. Sounds like a well meaning
> but flawed contribution by a new mapper who has now moved on from OSM.
>
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Is this a bad import or an experiment?

[Eric Ladner]

I think Ian is correct.  Looks like a mapping party.

I tracked back some of the editors and found other places around the
country (but mostly near LA) where residential areas were mapped with
excruciating detail, but sloppy drawing, bad tagging, etc. (see
https://www.openstreetmap.org/#map=19/34.16030/-117.41155 or
https://www.openstreetmap.org/#map=19/34.16718/-117.47586 as examples)

It needs more than tagging cleanup, IMO.  Drawing a 30 foot long driveway
as a closed "highway=service" that's not even connected to the main road is
just bad.  ~40,000 nodes in that one area for something that is close to
useless.  It looks pretty on the map, but it's really adding nothing to the
map intelligence wise (can't be used for routing, points out something
that's painfully obvious).  And the houses in one area (second link above),
everything in the yard was mapped EXCEPT the house, and in the houses'
case, it looks like they mapped something in the back yard or front yard
and tagged it as a building.

It's a shame because it's a lot of work by some people that are mapping in
a vacuum.  Their time would have been better spent by adding address nodes
and learning how to draw building footprints correctly.

On Wed, Mar 22, 2017 at 6:59 AM Ian Dees <ian.d...@gmail.com> wrote:

>
>
> On Mar 22, 2017 7:49 AM, "Paul Johnson" <ba...@ursamundi.org> wrote:
>
> On Wed, Mar 22, 2017 at 6:33 AM, Eric Ladner <eric.lad...@gmail.com>
> wrote:
>
> http://www.openstreetmap.org/#map=17/33.74152/-116.29677
>
> So much wrongness..  I don't even know where to start in describing it.
>
>
>  This really "feels" like a botched import that has the potential to
> become something actually good.  I've reached out.
> http://www.openstreetmap.org/changeset/38292137
>
>
> I noticed this yesterday when working on broken relations... It doesn't
> look like an import (mostly because they used iD and the digitization looks
> like hand drawn iD) but the tagging doesn't look right. I'd say it's a
> mapping project (they called it a "draw party") with good intentions but
> that might need some tagging cleanup.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Is this a bad import or an experiment?

[Eric Ladner]

http://www.openstreetmap.org/#map=17/33.74152/-116.29677

So much wrongness..  I don't even know where to start in describing it.

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

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Eric Ladner]

On Mon, Jun 20, 2016 at 8:08 PM Kevin Kenny 
wrote:

> The only way that I can see the current tagging working is if there
> is some hidden coupling where it is understood that tags that apply
> to an outer way of a multipolygon relation actually belong to the relation
> itself, and the inner ways are excluded implicitly. If so, that puzzles me,
> because that's also not what I see the renderer assuming.
>
> Can someone please explain to me how I should be tagging things
> so that the polygon-with-a-hole becomes a protected area? The ones I did
> in the Catskills, like https://www.openstreetmap.org/relation/6304902
> appear to render as I intended, but I know that there is lots of nonsense
> tagging that still renders prettily.
>
> Kevin
>

I think your perception of how multi-polygons work is correct.  Tagging
should be at the multipolygon level.  E.g. if it's a  park split by a road
maybe, both ways are members of the multipolygon, and the relation is
tagged with "type=multipolygon; leisure=park" and both ways with
"role=outer".  Maybe if there was something in the middle of the park, it'd
have a ring, that was tagged with nothing, but has "role=inner" on the
relation.  But, if it was a substation or lake or something, you could tag
the inner ring with natural=water or power=substation.

Granted, if you tagged the outer ways directly and left the relation with
nothing but "type=multipolygon" it would still render correctly, but it's
not the correct way to convey information.   Just because it looks pretty
on the map doesn't mean it's right.

JOSM flags this condition (tagging on outer ways instead of the MP itself)
as a warning when you're uploading.  That's probably a good indication it's
not a good practice.

Think of it from a data maintenance point of view.  If you have some huge
national park with 30 outer rings, do you want to manage 30 separate sets
of information on each outer way, or one set of information on the
multipolygon relation they all belong to anyway?

Eric
___
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 <kevin.b.ke...@gmail.com> 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 <eric.lad...@gmail.com>
> 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 <eric.lad...@gmail.com>
> wrote:
> >>
> >> I could fix it manually, if you like.  Pretty straight forward,
> actually.
> >>
> >> On Fri, Jun 17, 2016 at 4:22 AM Rihards <ric...@nakts.net> 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 <eric.lad...@gmail.com> wrote:

> I could fix it manually, if you like.  Pretty straight forward, actually.
>
> On Fri, Jun 17, 2016 at 4:22 AM Rihards <ric...@nakts.net> 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] 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] Best practices for dealing with old TIGER tags?

[Eric Ladner]

On Sat, Jun 4, 2016 at 5:01 PM Kevin Kenny 
wrote:

> I'm usually talking about mapping in much more remote areas, and I've
> been using 'track' more to denote more road quality. In some of the
> places I go, there are public rights-of-way that haven't been
> maintained by the counties in decades, that would still be lawful to
> drive on if you had a vehicle that could do it. They range from
> "completely grown to trees but you can most likely ride an ATV"
> through "mostly used for forestry, and high-clearance vehicles
> shouldn't have much problem, but don't try it in a passenger car" to
> "pea gravel and sugar sand that someone grades once a season, used as
> an auto road in the summer and a snowmobile track in the winter."


Isn't that what "tracktype=gradeX" is for?   The first case would be
highway=track; tracktype=grade5, the second probably tracktype=grade2 and
the last tracktype=grade1.  They're all highway=track (utility/farm vehicle
access), but just different grades (from grassy cow paths up to hard packed
gravel/clay roads that are, in some places, probably nicer than most back
water county paved roads.

You mentioned forestry, so naturally I think of logging roads.  Technically
it's public land, so there's no restriction to access, but for all intents
and purposes, they are highway=track.

The
> first is "highway=path" with appropriate notations for what uses are
> permitted, the second is "highway=track" (I could add "access=yes" but
> I thought that was the default for all highways); the third I'm less
> sure about, and I'm inconsistent between "track" and "unclassified"
> (with restrictions of 15 May-15 October, or whatever the season is).
> These are all roads where I have to keep reassuring my city-bred wife,
> "yes, this is a public road, even if it looks like an abandoned
> driveway!" when driving a 4WD down one.
>

General public access roads, though, in extreme rural areas where the road
is not what city folks would call a road -- probably would be unclassified
with a "surface" qualifier (unpaved, compacted, dirt, earth, whatever).

The description for highway=path says it's generally used for non-motorized
vehicles.  I'd prefer highway=unclassified, also with a surface qualifier.
But...

... I'm not bashing anybody over the head with my opinion, just stating an
alternate point of view.  I'm fine with whatever anybody wants to do as
long as it's consistent and has some kind of rationale behind it.

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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Eric Ladner]

On Sat, Jun 4, 2016 at 5:58 AM Greg Troxel  wrote:

>
> Kevin Kenny  writes:
>
> > OK, 'residential' if it looks like 'subdivision', 'unclassified'
> > otherwise (as long as it's drivable in, say, my daughter's car rather
> > than my 4-wheeler). Got it.
>
> I also see a distinction between residential/unclassified as denoting a
> legal road (around me, carved-out parcel wise from the surrounding land)
> vs track and some service denoting a non-legal-road.  However, others
> see the physical and legal attributes as separate.
>
>
My understanding of the description of "unclassified" is unclassified is a
step between residential and tertiary.   It's a connecting road, minor
connector, whatever, that doesn't have residential on it, but it's not high
enough in classification to make it a tertiary road.

I usually use it for roads in industrial complexes, loops around malls,
business complexes, or other connectors/roads where there's no obvious
residential around.

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

Re: [Talk-us] How are US county boundaries legally defined?

[Eric Ladner]

On Tue, May 31, 2016 at 8:48 AM Jake  wrote:

> ...
> On every map I can find - Boone Countys GIS dept., census.gov, US Forest
> Service - the county border strictly follows a river, Cedar Creek. However,
> on OSM, the boundary is shaped exactly like the river, but is shifted about
> a quarter mile north-east of it. Here's a small section to show what I mean:
>
> https://www.openstreetmap.org/#map=14/38.8117/-92.1427
>
> Now, I'm pretty sure this is a mistake - rivers move, but they don't shift
> in perfectly synchronized 40-mile segments like this.
>

Looks like the whole middle section got dragged as a bad edit or
something.  Data overlaid on USGS maps matches the surrounding area pretty
well, including the river.

If it were me, I'd just treat it as an error and correct it.  My guess is
you'll find that the GIS boundaries line up with the river (as does the
USGS map).

My 0.02.  Take it or leave it.

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

Re: [Talk-us] Dual carriage way?

[Eric Ladner]

On Sat, May 14, 2016 at 4:25 PM Mike N  wrote:

>
>I ran into this also in one local region where I converted many miles
> of dual carriageway TIGER into a single way because there was no
> divider, but mostly just had a center turning lane.
>
>
Thanks for all the replies.  I contacted the last editor and will wait for
his response.  If I don't hear anything in a couple of days, I'll probably
convert it.  There's no reason it should be dual ways.

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

[Talk-us] Dual carriage way?

[Eric Ladner]

http://www.openstreetmap.org/#map=16/30.0752/-90.5123

This section of West Airline Hwy was probably imported from Tiger as a dual
carriage way.

This section is two lanes in either direction with a center turning lane
for quite a few miles through town (no center divider).

I've converted a lot of "FIXME" single ways into dual one way highways, but
I've never converted one back the other way.

Before I embark on converting it to a single way, just wanted to get the
thoughts of other US mappers.

Thanks,

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

Re: [Talk-us] OSM attribution on website store locator pages

[Eric Ladner]

I'm glad to see that things are progressing through normal, friendly
discourse rather than the "talk to the hand" or "talk to our lawyers" that
some companies hide behind.

Great job, MapBox, and thanks for all the work you do!

Sincerely,

Eric Ladner
non-professional map junkie

On Fri, Apr 22, 2016 at 3:06 PM Mikel Maron <mikel.ma...@gmail.com> wrote:

> > "enterprise subscription" to MapBox, they are exempt from needing to
> include OSM attribution
>
> There's some confusion. OpenStreetMap attribution is always required --
> Mapbox enterprise users can elect to remove only the Mapbox attribution.
>
> We here at Mapbox are on this. More soon.
>
> -Mikel
>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
> ___
> 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] Fwd: State Park Boundary shp file

[Eric Ladner]

That seems unusual.  Most states have a GIS or Geospatial portal where most
of that information is easily downloadable.

E

On Thu, Jan 21, 2016 at 10:58 AM Paul Johnson  wrote:

> Would it be possible to get some advice on how to best submit this form
> for the outlines Oklahoma's state parks?  I'm not quite sure where "using
> the public record to assist in contributing to OpenStreetMap" lies on the
> binary option "personal" or "commercial" use, and ODRT basically said, "You
> want to know where the state park boundaries are?  File a FOIA Request..."
>  Who says red states favor small government? /s
>
> -- Forwarded message --
> From: Don Shafer 
> Date: Thu, Jan 21, 2016 at 10:19 AM
> Subject: State Park Boundary shp file
> To: "ba...@ursamundi.org" 
>
>
> Hi Paul,
>
>
>
> Don Shafer with the Oklahoma Tourism and Recreation Department.
>
>
>
> It has been brought to my attention that you have requested a boundary
> shape file of the State Parks.
>
>
>
> I’m sending our open records request document for you to fill out and send
> back to me and I will see that is gets to our Agencies General Council, who
> can make that determination.
>
>
>
> Thank you
>
> Don Shafer
>
>
>
> ___
> 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] [Imports] Importing Buildings and Addresses for Austin, Texas

[Eric Ladner]

I'll second Paul's bit rot on unique ID's comments.   They're all well and
good until somebody upgrades their GIS system, then all those unique ID's
get flushed down the drain.  And actually doing a conflation with hundreds
of thousands of buildings which may or may not have the ID's preserved over
years of editing is a daunting task in itself.

Also, I wouldn't be so concerned of the existing buildings.  Of the 4000 or
so existing buildings I looked at in Austin (and a good percentage of those
were the accidental import ones that I couldn't filter out), 90% of them
are poorly drawn contain only "building=yes" on them.  Most are hand drawn,
not orthogonal and only vaguely representative of the buildings on the
ground.

With the exception of the university buildings, it would be worth the time
to import the whole data set from CoA and find the conflicts at import time
and replace the existing geometry with the GIS system data.  I conflated
hundreds of buildings in the New Orleans import manually.  Time consuming?
Yes.  Worth it?  Yes.  The address data and decent building footprints
alone are worth it.

My 0.02.

On Mon, Nov 9, 2015 at 8:40 PM Andy Wilson <wilson.andre...@gmail.com>
wrote:

> On Mon, Nov 9, 2015 at 12:59 PM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > Am 09.11.2015 um 18:07 schrieb Eric Ladner <eric.lad...@gmail.com>:
>> >
>> > Replacing existing hand drawn buildings with imports from the city's
>> GIS system would probably be preferable given the quality of the hand drawn
>> buildings.  (compare the outline in [1] to satellite imagery).
>>
>>
>> it might depend, unlike the city's data the things in osm may vary a lot
>> in level of detail and quality. Also there could be other information
>> attached to these buildings so they should be carefully reviewed before any
>> deletions are executed.
>>
>>
>> cheers
>> Martin
>
>
>
> Thanks for taking time to look things over. Adding to what Martin said,
> some of our reasons:
>
> 1. From the belief that individual contributions are more valuable as a
> whole than contributions from an automated import process. We are trying to
> grow a local OSM community in Austin, and I feel that throwing away the
> work of past contributors works against that.
>
> 2. The data we are importing was collected about 3 years ago at this
> point, so OSM data will be more relevant and up to date in some cases.
>
> 3. Efficiency. There are enough buildings in OSM already and as Martin
> pointed out, comparing them individually and properly merging tags, etc
> would be time consuming.
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Importing Buildings and Addresses for Austin, Texas

[Eric Ladner]

Were steps taken to remove pre-existing buildings in OSM from the imported
data set?  As an example, see [1].

Looking at the data in the area, this seems the case, but I didn't
exhaustively search through all the files.  Replacing existing hand drawn
buildings with imports from the city's GIS system would probably be
preferable given the quality of the hand drawn buildings.  (compare the
outline in [1] to satellite imagery).

[1] http://www.openstreetmap.org/way/28570675


On Mon, Nov 9, 2015 at 8:13 AM Andy Wilson 
wrote:

> We would would like to import buildings and addresses for Austin, Texas
> and surrounding areas. Our plan on the OSM wiki:
> https://wiki.openstreetmap.org/wiki/Austin,_TX/Buildings_Import
> Processed data files for import can be found here:
> https://github.com/wilsaj/atx-buildings/tree/with-import-data/osm
>
> I should note that we had a bit of a false start on import the today. I
> thought we were ok to begin the import, but we were asked to stop. This is
> my fault; I misunderstood the import review process. We are now paused and
> awaiting feedback and approval from this list before continuing.
>
> If you could find time to look things over, we would really appreciate it.
>
> Thanks!
> ___
> 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] [OSM-talk] Find missing roads

[Eric Ladner]

I see some just north of Utica.   dozens of dots over all of New York if I
zoom out.

On Tue, Oct 13, 2015 at 3:52 AM Paul Johnson  wrote:

> On Wed, Oct 7, 2015 at 11:47 PM, Russ Nelson  wrote:
>
>> Martijn van Exel writes:
>>  > Hi all,
>>  >
>>  > Our OSM team cooked up something new. A missing roads plugin for JOSM.
>> I
>>  > think it's pretty nice but I would really like to hear what you think.
>>
>> Something's wrong -- there aren't any missing roads in NY (anymore)!!
>>
>
> Try other states?  ;o)
> ___
> 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] Should driveways be on OSM?

[Eric Ladner]

On Mon, Sep 28, 2015 at 12:37 PM Mike Thompson  wrote:

> On Sun, Sep 27, 2015 at 11:33 PM, Tom Bloom 
> wrote:
>
>> TIGER drew thousands of driveways that are often simply wrong.
>>
> I believe TIGER only includes driveways over a certain length.
>

Alabama seems to have a lot of driveways. I couldn't find one shorter than
50m so that may have been the cutoff. In a population area that's pretty
dense and the driveways are frequent and well defined, they don't add a lot
of value.

I agree with other respondents that long country driveways are worth
keeping if tagged correctly (highway=service / service=driveway).
Especially when the house sits way back from the road and the way to get to
the house may not be obvious.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)

[Eric Ladner]

On Mon, Sep 21, 2015 at 6:59 AM Greg Troxel  wrote:

>
> "Richie Kennedy"  writes:
>
> > To me, "unpaved" includes gravel surfaced roads (which is the
> > predominant surface type of non-state highways in rural Kansas). I'm
> > not inclined to mark every gravel road in Kansas as 'track'
>
> Unpaved does not at all imply track.  If it's a real road, open to the
> public, with a name, and expected to be used by normal vehicles, it's
> not a track.  track is about something that is physically less than a
> proper (even unpaved) road.
>
> It's perfectly reasonable to have an unpaved highway=secondary in
> rural areas, if that's one of the major roads around.
>
>

Agree. The OSM definintion of "track" is clear on this - "represents roads
for mostly agricultural use, forest tracks etc" and "Do not use tracks to
represent public unpaved roads in built-up areas". If it's an open road
with some kind of designation, then it's some level of highway, not a
track. Using a surface=* tag is crucial here.

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrack
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Long way in Lake County, CA no tags - broken boundary or other relation?

[Eric Ladner]

There are places where it roughly corresponds to the border of Boggs
Mountain State Forest.  It fairly well follows the outline on the USGS map
in certain places, but about 80-90 percent of the way wanders away
significantly (miles) from that border.  Agree that it's most likely not
useful.

On Thu, Sep 17, 2015 at 7:41 AM Andy Townsend  wrote:

> On 17/09/2015 13:20, Blake Girardot wrote:
> > Hi all,
> >
> > Could someone with some knowledge or expertise please investigate this
> > way:
> >
> > https://www.openstreetmap.org/way/158013854
> >
>
> A quick glance at
>
> http://osm.mapki.com/history/way.php?id=158013854
>
> suggests that it was created in
>
> http://osm.org/browse/changeset/11185320
>
> which appears to be an import.
>
> Some other ways created in that changeset have been deleted:
>
> http://www.openstreetmap.org/way/158014603
>
> (comment "Delete inaccurate imported landuse data")
>
> so I suspect that it's just more of the same.  The original importer's
> still active - if you're unsure I'd suggest asking them about it.  It
> appears unlikely that it's anything useful.
>
> Cheers,
>
> Andy (SomeoneElse)
>
>
> ___
> 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] Tagging National Forests

[Eric Ladner]

On Tue, Aug 18, 2015 at 9:02 AM Torsten Karzig torsten.kar...@web.de
wrote:

 As mentioned earlier part of the problem is a confusion between tagging
 what is there (landcover) and what it is used for (landuse). In the wiki we
 actually have a consistent approach (Approach 1) to make this distinction.
 Using natural=wood as a landcover tag and landuse=forest for areas of land
 managed for forestry. On top of this we of cause still have administrative
 boundaries.

 For me applying this to National Forests would mean:

 Using administrative boundaries to mark the entire National Forest.
 Remove the landuse=forest tag except for regions that are clearly used for
 forestry. This does not apply to most parts of the National forests in
 Southern California that I have seen. Although these areas are managed in
 the sense that someone administrates it (hence the administrative boundary)
 most parts of these National Forest are largely left alone and the
 possibility to collect deadwood does in my opinion not qualify as forestry.
 Finally, any larger regions that are covered with trees should be tagged as
 natural=wood. Other landcovers (scrub,water) can also be tagged as
 appropriate.

 The great advantage of the above tagging scheme is in my opinion that it
 is very easy to follow for the mapper on the ground. Knowing whether I am
 allowed to collect deadwood or not in a particular area is not easy to
 verify on the ground, and, in my opinion, not as important as defining
 landcovers or obvious landuses. Moreover, it is very confusing for someone
 that uses the map if there is a large green region marked as landuse=forest
 and on the ground there is no forestry, or obvious management, or trees.

 Torsten


Agree..

Not every square inch of a National Forest has (or will have) trees on it.
There are grasslands, mountains, lakes.

Plus, the stated goal of the USFS isn't solely to grow trees in a national
forest. Land management of these areas focuses on conservation, timber
harvesting, livestock grazing, watershed protection, wildlife, and
recreation.  So it's not all about the forest.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Tagging National Forests

[Eric Ladner]

On Mon, Aug 17, 2015 at 6:18 PM Mike Thompson miketh...@gmail.com wrote:

 The common meaning of forest is a large tract of land covered with
 trees and underbrush; woodland[1] However, many parts of US National
 Forests do not have trees, and either will never have trees, or will not
 have them for many decades, and therefore are not forested
 * Many ski resorts are within National Forests, e.g. [3]. Areas occupied
 by buildings, parking lots and most ski runs do not have trees and are not
 likely to for many years.
 * Areas above treeline do not have trees and will probably not have trees
 for centuries.
 * Meadows, prairies, lakes/reservoirs, areas of scree and mines[4] are all
 found within National Forests and no or few trees will exist in these areas

 Therefore significant parts of National Forests are not being used as a
 forest and tagging them as landuse=forest is not appropriate in my
 opinion.


+1

boundary=protected_area is more appropriate.

Modoc National Forest has large swaths of land (compare [1] and [2]) that
is not covered by trees, managed or not.  Tagging the whole area as
landuse=forest doesn't reflect what's actually on the ground.

I agree with an earlier poster (apologies, I forgot who) who suggested
replacing landuse=forest with landuse=timber.  timber has a more
unambiguous meaning than forest

[1] http://www.openstreetmap.org/#map=16/41.8233/-121.0963
[2] http://binged.it/1NCIf0Q
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us