Re: [Talk-us] [Imports] Import WestCOG building footprints in south-west Connecticut

[Martin Machyna]

So to update this thread, I have integrated addresses from CT Open Data
dataset and also updated the wiki page (
https://wiki.openstreetmap.org/wiki/Connecticut/Western_COG_Building_Import)

The whole dataset can be looked at:
https://drive.google.com/file/d/10hUl09WSmK-I8h1hkMlELIGwDYsEziSe/view?usp=sharing
For quick loading I also made a subset for one town (Westport):
https://drive.google.com/file/d/1oMSbHXpPY5eLSHhGlikGy2uudyq3VyoV/view?usp=sharing

If there is any issue, please let us know.

On the side note of the CT Open Data buildings suitability for import I
found a way how to simplify all buildings in an automated way in python.
Here is a quick comparison of before/after
https://files.slack.com/files-pri/T029HV94T-F01AD0FNFD3/simplified.png (you
need to have Slack account)
It doesn't look so bad and we could consider it for a next round of import.

Just for a future reference in case someone would need to do the same, the
python code is:

import geopandas as gpd
import pandas as pd
from shapely import speedups
speedups.enable()

address =
gpd.read_file("Connecticut_Buildings_with_Addresses_experimental.shp")
simple = address.simplify(0.05, preserve_topology=True)
simple.to_file('Buildings-simplified.geojson', driver='GeoJSON')



On Sat, Aug 29, 2020 at 6:50 PM  wrote:

> I was going to look at the buildings too.  I’ve used a tool in ArcGIS to
> correct some pretty awful buildings, but I couldn’t download them either.
>   If there is no hurry, I’d check in again with the contact on Monday.  It
> would be nice to have the buildings with addresses on them.
>
>
>
> Joe
>
>
>
> *From:* Yury Yatsynovich 
> *Sent:* Saturday, August 29, 2020 5:05 PM
> *To:* Julien Lepiller 
> *Cc:* impo...@openstreetmap.org; talk-us@openstreetmap.org
> *Subject:* Re: [Talk-us] [Imports] Import WestCOG building footprints in
> south-west Connecticut
>
>
>
> Hi Julien,
>
> Unfortunately, I have limited knowledge on the data quality as I wasn't
> able to download it (the server returns error). I let the CT point of
> contact (Scott) know about the problem -- he mentioned in our communication
> that he forwarded the issue to the tech support team, but I haven't heard
> from them since then and I'm still unable to download it.
>
>
>
> On Sat, Aug 29, 2020, 4:57 PM Julien Lepiller  wrote:
>
> So, it's been a week since that last message. Do you think we should
> import addresses and buildings at the same time? Should we import the
> buildings first and care about addresses later?
>
> Yury, what are your thoughts about the data source quality? Do you
> think it's a good idea to import from WestCOG and maybe rely on CT data
> for the rest of CT? I tried playing with the data and I didn't see any
> difference between drawing the buildings from scratch and having to
> simplify and correct CT's data.
>
> Thanks!
>
> Le Sat, 22 Aug 2020 19:36:23 -0400,
> Martin Machyna  a écrit :
>
> > Thank Julien for pushing this forward!
> >
> > yeah, I tried to get addresses from here:
> >
> http://geodata-ctmaps.opendata.arcgis.com/datasets/bfa7da83da384c2aa809882179369dc4_0/features/305004
> > and add them on top of the westCOG buildings.
> >
> > The data is a big mess because it's a join_table of like 30 different
> > address databases. I lost a bit of motivation there, but I could have
> > a look at it again.
> >
> > Martin
> >
> > On Sat, Aug 22, 2020 at 2:19 PM Julien Lepiller 
> > wrote:
> >
> > > Le Sat, 22 Aug 2020 13:30:02 -0400,
> > > Yury Yatsynovich  a écrit :
> > >
> > > > Hi Julien,
> > > > The following communication that I've had recently with a CT
> > > > official might be of interest to you:
> > > >
> > > >
> > >
> > > Oh, great! I think we already saw this data (I tried to contact them
> > > too, but never got a reply :/). From what we saw (I think it was in
> > > February?) the footprints have simplification issues (see
> > > https://files.slack.com/files-pri/T029HV94T-FTDGDHXTM/image.png for
> > > instance) where they are too detailed, not square enough, etc. Some
> > > buildings also have holes in them, when there's none in the imagery.
> > >
> > > So I think it's too bad to be used directly, without a lot of manual
> > > effort to simplify, square and redraw the shapes. However, the
> > > address data is very interesting, so maybe we could extract from
> > > it? Or we could use a separate dataset if they have addresses
> > > separately.
> > >
> > > ___
> > > Imports mailing list
> > > impo...@o

Re: [Talk-us] [Imports] Import WestCOG building footprints in south-west Connecticut

[joe.sapletal]

I was going to look at the buildings too.  I’ve used a tool in ArcGIS to 
correct some pretty awful buildings, but I couldn’t download them either.If 
there is no hurry, I’d check in again with the contact on Monday.  It would be 
nice to have the buildings with addresses on them.

 

Joe

 

From: Yury Yatsynovich  
Sent: Saturday, August 29, 2020 5:05 PM
To: Julien Lepiller 
Cc: impo...@openstreetmap.org; talk-us@openstreetmap.org
Subject: Re: [Talk-us] [Imports] Import WestCOG building footprints in 
south-west Connecticut

 

Hi Julien,

Unfortunately, I have limited knowledge on the data quality as I wasn't able to 
download it (the server returns error). I let the CT point of contact (Scott) 
know about the problem -- he mentioned in our communication that he forwarded 
the issue to the tech support team, but I haven't heard from them since then 
and I'm still unable to download it. 

 

On Sat, Aug 29, 2020, 4:57 PM Julien Lepiller mailto:o...@lepiller.eu> > wrote:

So, it's been a week since that last message. Do you think we should
import addresses and buildings at the same time? Should we import the
buildings first and care about addresses later?

Yury, what are your thoughts about the data source quality? Do you
think it's a good idea to import from WestCOG and maybe rely on CT data
for the rest of CT? I tried playing with the data and I didn't see any
difference between drawing the buildings from scratch and having to
simplify and correct CT's data.

Thanks!

Le Sat, 22 Aug 2020 19:36:23 -0400,
Martin Machyna mailto:mach...@gmail.com> > a écrit :

> Thank Julien for pushing this forward!
> 
> yeah, I tried to get addresses from here:
> http://geodata-ctmaps.opendata.arcgis.com/datasets/bfa7da83da384c2aa809882179369dc4_0/features/305004
> and add them on top of the westCOG buildings.
> 
> The data is a big mess because it's a join_table of like 30 different
> address databases. I lost a bit of motivation there, but I could have
> a look at it again.
> 
> Martin
> 
> On Sat, Aug 22, 2020 at 2:19 PM Julien Lepiller  <mailto:o...@lepiller.eu> >
> wrote:
> 
> > Le Sat, 22 Aug 2020 13:30:02 -0400,
> > Yury Yatsynovich  > <mailto:yury.yatsynov...@gmail.com> > a écrit :
> >  
> > > Hi Julien,
> > > The following communication that I've had recently with a CT
> > > official might be of interest to you:
> > >
> > >  
> >
> > Oh, great! I think we already saw this data (I tried to contact them
> > too, but never got a reply :/). From what we saw (I think it was in
> > February?) the footprints have simplification issues (see
> > https://files.slack.com/files-pri/T029HV94T-FTDGDHXTM/image.png for
> > instance) where they are too detailed, not square enough, etc. Some
> > buildings also have holes in them, when there's none in the imagery.
> >
> > So I think it's too bad to be used directly, without a lot of manual
> > effort to simplify, square and redraw the shapes. However, the
> > address data is very interesting, so maybe we could extract from
> > it? Or we could use a separate dataset if they have addresses
> > separately.
> >
> > ___
> > Imports mailing list
> > impo...@openstreetmap.org <mailto:impo...@openstreetmap.org> 
> > https://lists.openstreetmap.org/listinfo/imports
> >  


___
Talk-us mailing list
Talk-us@openstreetmap.org <mailto: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] Import WestCOG building footprints in south-west Connecticut

[Yury Yatsynovich]

Hi Julien,
Unfortunately, I have limited knowledge on the data quality as I wasn't
able to download it (the server returns error). I let the CT point of
contact (Scott) know about the problem -- he mentioned in our communication
that he forwarded the issue to the tech support team, but I haven't heard
from them since then and I'm still unable to download it.

On Sat, Aug 29, 2020, 4:57 PM Julien Lepiller  wrote:

> So, it's been a week since that last message. Do you think we should
> import addresses and buildings at the same time? Should we import the
> buildings first and care about addresses later?
>
> Yury, what are your thoughts about the data source quality? Do you
> think it's a good idea to import from WestCOG and maybe rely on CT data
> for the rest of CT? I tried playing with the data and I didn't see any
> difference between drawing the buildings from scratch and having to
> simplify and correct CT's data.
>
> Thanks!
>
> Le Sat, 22 Aug 2020 19:36:23 -0400,
> Martin Machyna  a écrit :
>
> > Thank Julien for pushing this forward!
> >
> > yeah, I tried to get addresses from here:
> >
> http://geodata-ctmaps.opendata.arcgis.com/datasets/bfa7da83da384c2aa809882179369dc4_0/features/305004
> > and add them on top of the westCOG buildings.
> >
> > The data is a big mess because it's a join_table of like 30 different
> > address databases. I lost a bit of motivation there, but I could have
> > a look at it again.
> >
> > Martin
> >
> > On Sat, Aug 22, 2020 at 2:19 PM Julien Lepiller 
> > wrote:
> >
> > > Le Sat, 22 Aug 2020 13:30:02 -0400,
> > > Yury Yatsynovich  a écrit :
> > >
> > > > Hi Julien,
> > > > The following communication that I've had recently with a CT
> > > > official might be of interest to you:
> > > >
> > > >
> > >
> > > Oh, great! I think we already saw this data (I tried to contact them
> > > too, but never got a reply :/). From what we saw (I think it was in
> > > February?) the footprints have simplification issues (see
> > > https://files.slack.com/files-pri/T029HV94T-FTDGDHXTM/image.png for
> > > instance) where they are too detailed, not square enough, etc. Some
> > > buildings also have holes in them, when there's none in the imagery.
> > >
> > > So I think it's too bad to be used directly, without a lot of manual
> > > effort to simplify, square and redraw the shapes. However, the
> > > address data is very interesting, so maybe we could extract from
> > > it? Or we could use a separate dataset if they have addresses
> > > separately.
> > >
> > > ___
> > > Imports mailing list
> > > impo...@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/imports
> > >
>
>
> ___
> 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] Import WestCOG building footprints in south-west Connecticut

[Julien Lepiller]

So, it's been a week since that last message. Do you think we should
import addresses and buildings at the same time? Should we import the
buildings first and care about addresses later?

Yury, what are your thoughts about the data source quality? Do you
think it's a good idea to import from WestCOG and maybe rely on CT data
for the rest of CT? I tried playing with the data and I didn't see any
difference between drawing the buildings from scratch and having to
simplify and correct CT's data.

Thanks!

Le Sat, 22 Aug 2020 19:36:23 -0400,
Martin Machyna  a écrit :

> Thank Julien for pushing this forward!
> 
> yeah, I tried to get addresses from here:
> http://geodata-ctmaps.opendata.arcgis.com/datasets/bfa7da83da384c2aa809882179369dc4_0/features/305004
> and add them on top of the westCOG buildings.
> 
> The data is a big mess because it's a join_table of like 30 different
> address databases. I lost a bit of motivation there, but I could have
> a look at it again.
> 
> Martin
> 
> On Sat, Aug 22, 2020 at 2:19 PM Julien Lepiller 
> wrote:
> 
> > Le Sat, 22 Aug 2020 13:30:02 -0400,
> > Yury Yatsynovich  a écrit :
> >  
> > > Hi Julien,
> > > The following communication that I've had recently with a CT
> > > official might be of interest to you:
> > >
> > >  
> >
> > Oh, great! I think we already saw this data (I tried to contact them
> > too, but never got a reply :/). From what we saw (I think it was in
> > February?) the footprints have simplification issues (see
> > https://files.slack.com/files-pri/T029HV94T-FTDGDHXTM/image.png for
> > instance) where they are too detailed, not square enough, etc. Some
> > buildings also have holes in them, when there's none in the imagery.
> >
> > So I think it's too bad to be used directly, without a lot of manual
> > effort to simplify, square and redraw the shapes. However, the
> > address data is very interesting, so maybe we could extract from
> > it? Or we could use a separate dataset if they have addresses
> > separately.
> >
> > ___
> > Imports mailing list
> > impo...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/imports
> >  


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

Re: [Talk-us] [Imports] Potential Import of Addresses for Thurston County, WA, USA

[Raven King]

One solution might be to modify the dataset then provide some upload of
the modified dataset as the source?

My understanding is that yes it could. The goal is that they do want to
be seen as responsible if we modify the data in any way that is
incorrect, nor do they want us to represent them in any official
capacity.

On Wed, 2020-08-26 at 06:07 +0200, Mateusz Konieczny via Imports wrote:
> Is specifying source in changeset
> or on import page on Wiki qualifying
> as crediting them?
> 
> Because doing this is actually required.
> 
> 
> 26 Aug 2020, 02:07 by thekingofrav...@disroot.org:
> > Alright I have an update:
> > 
> > After an email chain with Thurston County GeoData Center, I finally
> > got
> > explicit permission to use the data in open street map. 
> > 
> > "Hello Raven,
> > 
> > You can use the data in Open Street Maps and credit GeoData UNLESS
> > you
> > change the data in any way. If you change the data you can still
> > use it
> > in Open Street Maps but CANNOT credit GeoData and the County. We
> > make
> > no warrantees about the data temporally, spatially, or in terms of
> > attribution.
> > 
> > Please let me know if this helps to clarify the disclaimer or if
> > you
> > still have questions.
> > 
> > Thank you!
> > 
> > Leslie Carman
> > GIS Analyst I"
> > 
> > I can provide the entire email chain if required but this is the
> > part
> > that matters. As for the terms they gave me, what is the best way
> > of handling this? My instinct is just to, in some very minor way,
> > ensure every piece of data is modified somehow so future mappers do
> > not have to worry about it. Does just adding it to OSM count as
> > modification, since we convert the data fields?
> > 
> > At this point, I would like to propose that we import this data, as
> > this includes rural towns and unincorporated thurston
> > county.
> > I would divide the building footprints into small blocks to avoid
> > well
> > mapped areas.
> > As for addresses, because they are points and there are so few
> > addresses in my region, I feel like we could be more aggresive
> > about
> > that import, although how much so I am not certain.
> > 
> > 
> > Also @Clifford Snow if you see this I would appreciate whatever you
> > have to teach about imports. 
> > 
> > Sincerely,
> > Raven
> > 
> > 
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
> 
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports


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

Re: [Talk-us] [Imports] Import WestCOG building footprints in south-west Connecticut

[Martin Machyna]

Thank Julien for pushing this forward!

yeah, I tried to get addresses from here:
http://geodata-ctmaps.opendata.arcgis.com/datasets/bfa7da83da384c2aa809882179369dc4_0/features/305004
and add them on top of the westCOG buildings.

The data is a big mess because it's a join_table of like 30 different
address databases. I lost a bit of motivation there, but I could have a
look at it again.

Martin

On Sat, Aug 22, 2020 at 2:19 PM Julien Lepiller  wrote:

> Le Sat, 22 Aug 2020 13:30:02 -0400,
> Yury Yatsynovich  a écrit :
>
> > Hi Julien,
> > The following communication that I've had recently with a CT official
> > might be of interest to you:
> >
> >
>
> Oh, great! I think we already saw this data (I tried to contact them
> too, but never got a reply :/). From what we saw (I think it was in
> February?) the footprints have simplification issues (see
> https://files.slack.com/files-pri/T029HV94T-FTDGDHXTM/image.png for
> instance) where they are too detailed, not square enough, etc. Some
> buildings also have holes in them, when there's none in the imagery.
>
> So I think it's too bad to be used directly, without a lot of manual
> effort to simplify, square and redraw the shapes. However, the address
> data is very interesting, so maybe we could extract from it? Or we
> could use a separate dataset if they have addresses separately.
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Import WestCOG building footprints in south-west Connecticut

[Julien Lepiller]

Le Sat, 22 Aug 2020 13:30:02 -0400,
Yury Yatsynovich  a écrit :

> Hi Julien,
> The following communication that I've had recently with a CT official
> might be of interest to you:
> 
> 

Oh, great! I think we already saw this data (I tried to contact them
too, but never got a reply :/). From what we saw (I think it was in
February?) the footprints have simplification issues (see
https://files.slack.com/files-pri/T029HV94T-FTDGDHXTM/image.png for
instance) where they are too detailed, not square enough, etc. Some
buildings also have holes in them, when there's none in the imagery.

So I think it's too bad to be used directly, without a lot of manual
effort to simplify, square and redraw the shapes. However, the address
data is very interesting, so maybe we could extract from it? Or we
could use a separate dataset if they have addresses separately.

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

Re: [Talk-us] [Imports] Import WestCOG building footprints in south-west Connecticut

[Yury Yatsynovich]

Hi Julien,
The following communication that I've had recently with a CT official might
be of interest to you:


*

Hi Yury,



At this point, yes, I think that’s correct. Obviously, we’d like if you
cite the state, but we don’t have set guidelines for that. I forwarded the
other issue with downloading data and will let you know what I hear.
Hide quoted text



Thanks,



Scott



*From:* Yury Yatsynovich 
*Sent:* Monday, August 3, 2020 8:53 AM
*To:* Gaul, Scott 
*Subject:* Re: Request for permission to import data into OpenStreetMap



Thank you,  Scott!

The above mentioned terms describe mostly (lack of) liabilities of the data
provider, but don't mention any constraints on who and how can use the
data. Does it mean that there are no such constraints? There is also no
attribution requirement -- does it mean that I'm not required to cite the
source of the data?

With best regards,



On Mon, Aug 3, 2020, 7:42 AM Gaul, Scott  wrote:

Hi Yury,

Thanks for asking – you can use the terms of use for the CT open data
portal, here: https://data.ct.gov/terms. That should also cover the GIS
portal. Let us know any questions.



Thanks,



Scott



*From:* Yury Yatsynovich 
*Sent:* Friday, July 31, 2020 3:57 PM
*To:* Gaul, Scott 
*Subject:* Request for permission to import data into OpenStreetMap



Hi Scott!

Are there any constraints on who and how is allowed to use the data posted
on http://geodata-ctmaps.opendata.arcgis.com

?

I'm asking this because I'm interested in importing the data on CT
buildings with addresses into OpenStreetMap (OSM) -- to do so I need to
make sure that the imported data's license is compatible with OSM.

With kind regards,

OSM contributor,

--

Yury Yatsynovich


On Sat, Aug 22, 2020, 1:17 PM Julien Lepiller  wrote:

> Hi!
>
> With other contributors in Connecticut, we would like to import
> building footprints. We have evaluated different data sources, and
> concluded that no Connecticut-wide sources were usable without a lot of
> manual work to fix building geometry.
>
> We found that the WestCOG has very accurate building footprint data on
> its territory (south west Connecticut), available online and with a
> compatible license (CC0):
> http://data.westcog.org:8080/GIS_data/Buildings.gdb.zip
> That's 513,141 buildings, and 296,423 building parts in some of them,
> that cover this territory:
>
> https://westcog.org/wp-content/uploads/2015/08/WestCOG_Locus_Map-e1439920850177-790x1024.jpg
>
> Other COGs unfortunately don't share this data online. We hope that a
> successful import could be a convincing argument for other COGs to open
> their data.
>
> We have documented our current plan at
> https://wiki.openstreetmap.org/wiki/Connecticut/Western_COG_Building_Import
> on the wiki.
>
> We have contacted local mappers of this part of
> Connecticut (we are based in and around New Haven, not is south-west
> Connecticut), with no negative feedback and 2-3 positive responses. We
> have created a process to convert the data from WestCOG to OSM tags and
> files that can easily be loaded in JOSM.
>
> We have never done an import before, so we'd appreciate any advice on
> how to properly do the import. From our reading the wiki, we should use
> a separate user to import the data. Is that one shared user for the
> import, or one user for each person importing data?
>
> We have identified potential issues with this import: roads and
> waterways come from an old import and might very well cross the
> buildings we'd like to import. For now, we have a task on the osmus
> task manager to try and correct road geometry (currently finished at
> 50%) that covers Fairfield County (WestCOG is a part of Fairfield
> county): https://tasks.openstreetmap.us/project/193. This is not going
> very fast, so we'd like to start the import even though we haven't
> finished the tasks. We plan to fix road and water issues as we
> encounter them instead, while encouraging people to go and fix them
> independently from our import.
>
> WestCOG currently has almost no building mapped, but obviously we plan
> to keep existing buildings and only import buildings that are not yet
> mapped.
>
> What is a good way to split this import? Is there a good size per
> changeset that you could recommend?
>
> Thanks for your help!
>
> Julien
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Import of Orange County, California Buildings and Addresses

[Clifford Snow]

Tod,
You might want to look into Paul Norman's ogr2osm.py [1] python tool which
can translate shapefiles into .osm files that can be uploaded using JOSM.
It's simple to use, just need to create a translation file for shapefile
fields to OSM tag.

I'm in the process of doing an import of building and addresses for
Marysville, WA. Way smaller than you import. The import page is
https://wiki.openstreetmap.org/wiki/Marysville_Import which has links to my
code including the ogr2osm.py translation scripts.

Feel free to contact me offline if you have any questions.

Best,
Clifford

[1] https://github.com/pnorman/ogr2osm

On Tue, Jul 28, 2020 at 3:06 PM Tod Fitch  wrote:

> I'm planning an import of buildings and addresses for Orange County,
> California. Information on the proposed import can be found on the wiki at
> https://wiki.openstreetmap.org/wiki/Orange_County_Building_and_Address_Import
>
> This is a one time import using JOSM.
>
> A links to the data being imported given on the wiki and the data is
> marked as public domain.
>
> Note: There is an effort by ERSI to make this same dataset available to
> mappers working with the RapiD data via MapWithAI. For a description of
> that, see
> https://wiki.openstreetmap.org/wiki/Import/Orange_County,_California_Buildings
>
> This is my first attempt at an import so gentle guidance on following best
> procedures will be appreciated.
>
> Regards,
> Tod
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports-us] Interested in importing address points in New York State

[Matthew Woehlke]

On 16/07/2020 00.44, Skyler Hawthorne wrote:
Reading up on the import guidelines, I can see that the license is 
important. However, I am not able to see anything that explicitly states 
one way or another what kind of license the data sets are distributed 
under, and this whether or not it is compatible with the ODBL.


Hello again! Great to see someone else working in my neck of the woods!

If the site doesn't state clearly (an issue I had with Prince William 
County, VA, which I have been working on for job-related reasons), I 
would recommend contacting the data issuing agency. I see it's a .ny.gov 
site, so it's almost surely legitimate (plus it's hard to imagine 
someone making the effort to set up a scam site with enough content to 
not be obvious).


There are some form letters you can use to ask if the data is available 
under a compatible license, or you can just ask them to clearly indicate 
the license *or if the data is Public Domain*. In my experience, it may 
be helpful to ask up front for the contact to clearly state if the data 
is or is not PD.


As a disclaimer, I do this in my free time, which is in short supply, so 
progress on this would likely be slow. However, I would love if everyone 
could just search for any address and find it.


As someone who recently went looking and discovered that his former 
residence "doesn't exist" in OSM, I for one will be most gratified to 
see any improvements in the area :-).


--
Matthew

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

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Clifford Snow]

I asked the Jamestown S'Klallam Tribe, near Sequim, WA for updated
boundaries. The state boundaries did not match what was on the tribes
website. They provided me with an update - the same one they just sent the
Census Bureau. With the 2020 census my guess is that TIGER might have some
good boundaries. (I didn't ask, but found it interesting that Census came
directly to the tribe instead of BIA.)

Jamestown S'Klallam brings up the question of rendering off reservation
trust lands. I asked Jamestown, they recommended rendering it differently.
For those not on Slack, I asked the same question there - should we create
a rendering for off reservation trust lands? This tribe is a good example
of why we might want to. They have substantially more off reservation lands
than reservation lands. The tribe closest to me (Swinomish) has one small
lot of off reservation land, but a large reservation. They could probably
care less. (The lot is located in downtown La Conner - a small tourist town
nearby. It's not in OSM. )

I'd like others opinion of rendering. Washington maybe totally different
than the rest of the country.

Happy New Years All,
Clifford

On Fri, Dec 20, 2019 at 5:22 PM Paul Johnson  wrote:

> On Fri, Dec 20, 2019 at 7:18 PM Clifford Snow 
> wrote:
>
>> I've reached out to a couple of the nearby reservations, one with a small
>> parcel of off reservation land trust, the other with only a small
>> reservation but a very large off reservation land trust. I don't expect
>> answers until possibly after the new year. Unlike Oklahoma, Washington
>> reservations are pretty straight forward. The Yakama Nation has a large
>> disputed area but I'm inclined to show it as reservation land. I haven't
>> updated it yet because the borders are tied up in multiple relations that
>> need undoing.
>>
>
> Well, that's mostly fortunate.  The disputed area and definitely Fort
> Simcoe would be potentially sore spots to look out for and look into more
> if reasonable.
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Paul Johnson]

On Fri, Dec 20, 2019 at 7:18 PM Clifford Snow 
wrote:

> I've reached out to a couple of the nearby reservations, one with a small
> parcel of off reservation land trust, the other with only a small
> reservation but a very large off reservation land trust. I don't expect
> answers until possibly after the new year. Unlike Oklahoma, Washington
> reservations are pretty straight forward. The Yakama Nation has a large
> disputed area but I'm inclined to show it as reservation land. I haven't
> updated it yet because the borders are tied up in multiple relations that
> need undoing.
>

Well, that's mostly fortunate.  The disputed area and definitely Fort
Simcoe would be potentially sore spots to look out for and look into more
if reasonable.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Paul Johnson]

(Conversational quoting, please)

On Fri, Dec 20, 2019 at 6:42 PM David Bartecchi 
wrote:

> All of these concerns must be weighed against the fact that the current
> absence of Native lands in OSM only contributes to the erasure Native
> Americans and their lands from the American collective conscience.
>

Agreed.

I did think ahead on this enough to use the protected lands key when
tagging the areas I have mapped so far, as this is probably the most
neutral method available right now that doesn't break the renderers.  Not
good enough for government work (we'd need a lot more research into treaty
status and way more admin values to make those value judgements as
administrative areas), but good enough to at least be a starting point for
well established areas.

My more immediate concern than "not erasing people" is "not assigning areas
to people in ways that are ambiguous, irrelevant or potentially perceived
as hostile".  I'm not the person to take the lead on navigating that one.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Clifford Snow]

I've reached out to a couple of the nearby reservations, one with a small
parcel of off reservation land trust, the other with only a small
reservation but a very large off reservation land trust. I don't expect
answers until possibly after the new year. Unlike Oklahoma, Washington
reservations are pretty straight forward. The Yakama Nation has a large
disputed area but I'm inclined to show it as reservation land. I haven't
updated it yet because the borders are tied up in multiple relations that
need undoing.

Best,
Clifford

On Fri, Dec 20, 2019 at 4:42 PM David Bartecchi 
wrote:

> All of these concerns must be weighed against the fact that the current
> absence of Native lands in OSM only contributes to the erasure Native
> Americans and their lands from the American collective conscience.
>
> Dave
>
> On Fri, Dec 20, 2019 at 5:27 PM Paul Johnson  wrote:
>
>> Content warning: Aboriginal abuse mention
>>
>> On Fri, Dec 20, 2019 at 2:08 PM Clifford Snow 
>> wrote:
>>
>>> I do have Washington State tribal lands available [1]  as a background
>>> layer for JOSM. There is also a vector tile layer [2] of the same
>>> background available for iD users.
>>>
>>> The data contains the name in english and the land type of Disputed
>>> Area, Off-Reservation Trust Land, Reservation, and Tribal Headquarters.
>>> Only 4 disputed areas but 60 Off-Reservation areas. Some people include
>>> Off-Reservation in tribal lands while others do not. My sense is that they
>>> should be tagged as boundary=aboriginal_lands. I'd like to hear the opinion
>>> of the group.
>>>
>>
>> The TLDR: I, personally, have not been including trust lands in Oklahoma,
>> for pragmatic reasons.  The situation is complicated, painful to many, and
>> politically loaded on a level where I don't think OSM should sort out trust
>> lands yet.
>>
>> I'm aware of several dozen trust exclaves, but they all fall into one of
>> three categories.
>>
>>1. The exclave is presently unclaimed or claimed but no longer
>>occupied by multiple tribes, and thus the status is ambiguous other than
>>it's within BIA jurisdiction.  Most Oklahoma exclaves fall into this
>>category, and it's really complicated.
>>2. The exclave is claimed by one tribe but it's ability to establish
>>a presence and primary jurisdiction is in question.  There's an exclave in
>>Boise, OK where one of the tribes (not sure which, but pretty sure not
>>mine) presently has plans to open a travel center and casino, however, 
>> this
>>exclave is hundreds of kilometers from their jurisdictional area and
>>whether or not they can even claim the exclave is nebulous.  It's
>>effectively tribal terra nullius.
>>3. The Chilocco Indian Residential School.  This one gets super
>>touchy.  The school, which closed in 1980, has sat abandoned and uncared
>>for since, yet can't be torn down without considerable red tape since the
>>site is on the National Historic Register.  The school is currently
>>assigned to five additional tribes in the immediate region, and they
>>cooperatively ran a rehabilitation center for the school's victims at the
>>site in the 1990s and 2000s, but the rehab facility has also sat abandoned
>>since at least 2011 with no plans for the site, and the whole enclave
>>currently is off limits to everyone, very intermittently used as a 
>> training
>>ground for federal police agencies, further rubbing sandpaper into 
>> unhealed
>>wounds for many.  No surprise, the original school that operated for 98
>>years is widely criticized for most of its existence, and especially in 
>> its
>>final decade of operation, for being little more than a concentration camp
>>for indian children as part of the US's plan for Americanization of
>>indians. As far as I can tell, abuse at the school was institutionalized,
>>frequent and persistent enough it's hard not to imagine it wasn't by
>>design.  It might as well be scorched earth.
>>
>> Add this into the fact that not all of Oklahoma's tribes (or even the
>> relevant tribes that potentially have claim to these parcels) get along
>> with each other.  Add that Governor Stitt has been talking about cancelling
>> state compacts with the tribes this month, and we're actually seeing nearly
>> unprecedented intertribal unity and cooperation right now (weird how a
>> common threat does that).
>>
>> All that said, my read on the situation?  Trying to sort out the trust
>> lands in Oklahoma is politically shaky at best for OSM, and it wouldn't
>> surprise me if similar situations are present in other states.  Offhand,
>> Pennsylvania, Oregon and Kansas all have federal indian schools presently
>> in operation (Army War College in Carlisle, Chemawa in Salem, and Haskell
>> Indian College in Haskell respectively).  Washington State had one as well
>> (Fort Simcoe), and presently has a far darker and ongoing relations with
>> the tribes in that state most 

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Paul Johnson]

Content warning: Aboriginal abuse mention

On Fri, Dec 20, 2019 at 2:08 PM Clifford Snow 
wrote:

> I do have Washington State tribal lands available [1]  as a background
> layer for JOSM. There is also a vector tile layer [2] of the same
> background available for iD users.
>
> The data contains the name in english and the land type of Disputed Area,
> Off-Reservation Trust Land, Reservation, and Tribal Headquarters. Only 4
> disputed areas but 60 Off-Reservation areas. Some people include
> Off-Reservation in tribal lands while others do not. My sense is that they
> should be tagged as boundary=aboriginal_lands. I'd like to hear the opinion
> of the group.
>

The TLDR: I, personally, have not been including trust lands in Oklahoma,
for pragmatic reasons.  The situation is complicated, painful to many, and
politically loaded on a level where I don't think OSM should sort out trust
lands yet.

I'm aware of several dozen trust exclaves, but they all fall into one of
three categories.

   1. The exclave is presently unclaimed or claimed but no longer occupied
   by multiple tribes, and thus the status is ambiguous other than it's within
   BIA jurisdiction.  Most Oklahoma exclaves fall into this category, and it's
   really complicated.
   2. The exclave is claimed by one tribe but it's ability to establish a
   presence and primary jurisdiction is in question.  There's an exclave in
   Boise, OK where one of the tribes (not sure which, but pretty sure not
   mine) presently has plans to open a travel center and casino, however, this
   exclave is hundreds of kilometers from their jurisdictional area and
   whether or not they can even claim the exclave is nebulous.  It's
   effectively tribal terra nullius.
   3. The Chilocco Indian Residential School.  This one gets super touchy.
   The school, which closed in 1980, has sat abandoned and uncared for since,
   yet can't be torn down without considerable red tape since the site is on
   the National Historic Register.  The school is currently assigned to five
   additional tribes in the immediate region, and they cooperatively ran a
   rehabilitation center for the school's victims at the site in the 1990s and
   2000s, but the rehab facility has also sat abandoned since at least 2011
   with no plans for the site, and the whole enclave currently is off limits
   to everyone, very intermittently used as a training ground for federal
   police agencies, further rubbing sandpaper into unhealed wounds for many.
   No surprise, the original school that operated for 98 years is widely
   criticized for most of its existence, and especially in its final decade of
   operation, for being little more than a concentration camp for indian
   children as part of the US's plan for Americanization of indians. As far as
   I can tell, abuse at the school was institutionalized, frequent and
   persistent enough it's hard not to imagine it wasn't by design.  It might
   as well be scorched earth.

Add this into the fact that not all of Oklahoma's tribes (or even the
relevant tribes that potentially have claim to these parcels) get along
with each other.  Add that Governor Stitt has been talking about cancelling
state compacts with the tribes this month, and we're actually seeing nearly
unprecedented intertribal unity and cooperation right now (weird how a
common threat does that).

All that said, my read on the situation?  Trying to sort out the trust
lands in Oklahoma is politically shaky at best for OSM, and it wouldn't
surprise me if similar situations are present in other states.  Offhand,
Pennsylvania, Oregon and Kansas all have federal indian schools presently
in operation (Army War College in Carlisle, Chemawa in Salem, and Haskell
Indian College in Haskell respectively).  Washington State had one as well
(Fort Simcoe), and presently has a far darker and ongoing relations with
the tribes in that state most readily comparable Canada's Highway of Tears,
but more widespread.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Paul Johnson]

On Thu, Dec 19, 2019 at 3:03 PM Mike Thompson  wrote:

> > I've avoided BIA because their data doesn't seem accurate
> We have gotten some additional feedback off list also suggesting that the
> BIA data may not be as accurate as some other sources.  Perhaps we should
> create a wiki page listing every reservation, its boundary status in OSM,
> and the known sources of data.  Mappers can then "sign up" to work on
> individual reservation boundaries (by adding their name to the wiki page),
> manually comparing the various sources, researching the most correct
> representation, and of course editing OSM to reflect their findings
> just thinking out loud here.--
>

I'm feeling this a lot more than the MapRoulette idea.  Especially if we
can get local participants involved.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Mike Thompson]

Clifford,

Thanks for your feedback.

> I've avoided BIA because their data doesn't seem accurate
We have gotten some additional feedback off list also suggesting that the
BIA data may not be as accurate as some other sources.  Perhaps we should
create a wiki page listing every reservation, its boundary status in OSM,
and the known sources of data.  Mappers can then "sign up" to work on
individual reservation boundaries (by adding their name to the wiki page),
manually comparing the various sources, researching the most correct
representation, and of course editing OSM to reflect their findings
just thinking out loud here.

Mike

On Wed, Dec 18, 2019 at 10:10 AM Clifford Snow 
wrote:

> Mike,
> Thanks to you, David and Paul for taking the initiative to mapping Natiive
> American Reservations. On and off for the last few years I've been
> attempting to reservations mapped in Washington State. My first choice for
> boundary information has always been from the reservation then the state.
> I've avoided BIA because their data doesn't seem accurate, at least at the
> time when I first started adding reservations. I look forward to seeing how
> it compares to the boundaries I added.
>
> I especially applaud your desire to involve Native American youth in the
> project. I have struggled to make any headway getting the tribes involved.
> Related to that I've been asking people I know that work for the tribes
> about adding features in their native language. A number of the tribes
> around me are working hard to ensure their languages not only survives but
> flourishes. I'm hoping with my connections I can partner with the tribe get
> them to actively contribute to OSM using their native language. It is
> something you might also consider doing.
>
> Let me know how I can help,
> Clifford
>
> On Tue, Dec 17, 2019 at 4:35 PM Mike Thompson  wrote:
>
>>
>> Village Earth's Native Land Advocacy Project[1], David Bartecchi[2], Paul
>> Johnson[3], and I[4] are considering an organized effort to improve the
>> boundaries of Native American Reservations in the US.  We have studied the
>> import guidelines on the wiki and will follow those, however, we first
>> wanted to see:
>>
>> 1) If there was any fundamental objection to this idea before even the
>> details are spelled out
>>
>> 2) If anyone is already working on this issue.
>>
>> 3) If anyone would like to join us.
>>
>>
>> We are thinking that our general approach will be:
>>
>> 1) Use data from this source:
>> https://biamaps.doi.gov/dataDownload/index.htmlIt has a compatible
>> license, but will verify and document as part of this process.
>>
>> 2) Somehow allow mappers to "check out" a particular reservation's
>> boundary.  Exact mechanism is TBD.
>>
>> 3) A human mapper will examine each boundary individually
>>
>> 4) Where OSM does not have a corresponding reservation boundary, the
>> mapper will import the boundary into OSM (not sure of the exact mechanics
>> at this time).  If the boundary needs to participate in a boundary
>> relation, that will be handled here. Tag mapping is TBD at this point.
>> Any conflicts with existing OSM features will be addressed in this step.
>>
>> 5) Where OSM has a boundary and it does not match the above source, and
>> it has not been edited by a human mapper, proceed as in 4 above, except
>> only replace geometry and preserve the history of the existing OSM
>> features.
>>
>> 6) Where OSM has a boundary and it does not match our source, but it has
>> been edited by a human mapper, use additional sources, including tribal
>> sources, and county sources, to determine the true boundary and make
>> necessary edits in OSM.  Deference will be given to the edits made by local
>> mappers.
>>
>> To be determined:
>> We are aware of some cases where different government bodies (e.g.
>> Federal Government vs. a state government) dispute the extent of a
>> reservation.
>>
>> Long term we would like to involve Native Americans, particularly youth
>> living on reservations, in adding additional details to OSM about
>> reservations, such as street names, amenities, etc., but we don't envision
>> this as part of this import/organized effort process.
>>
>> We look forward to your initial feedback on this preliminary concept.
>>
>> Mike
>>
>>
>> [1] Village Earth is a 501(c)(3) nonprofit organization that has worked
>> in Indian Country for over 20 years and works closely with the Indian Land
>> Tenure Foundation
>> [2] David works for Village Earth
>> [3] Most people on this list are probably familiar with Paul, a long time
>> contributor to OSM
>> [4] My OSM user name is tekim, I have been mapping in OSM since 2009.
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
___
Talk-us mailing list

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Clifford Snow]

Mike,
Thanks to you, David and Paul for taking the initiative to mapping Natiive
American Reservations. On and off for the last few years I've been
attempting to reservations mapped in Washington State. My first choice for
boundary information has always been from the reservation then the state.
I've avoided BIA because their data doesn't seem accurate, at least at the
time when I first started adding reservations. I look forward to seeing how
it compares to the boundaries I added.

I especially applaud your desire to involve Native American youth in the
project. I have struggled to make any headway getting the tribes involved.
Related to that I've been asking people I know that work for the tribes
about adding features in their native language. A number of the tribes
around me are working hard to ensure their languages not only survives but
flourishes. I'm hoping with my connections I can partner with the tribe get
them to actively contribute to OSM using their native language. It is
something you might also consider doing.

Let me know how I can help,
Clifford

On Tue, Dec 17, 2019 at 4:35 PM Mike Thompson  wrote:

>
> Village Earth's Native Land Advocacy Project[1], David Bartecchi[2], Paul
> Johnson[3], and I[4] are considering an organized effort to improve the
> boundaries of Native American Reservations in the US.  We have studied the
> import guidelines on the wiki and will follow those, however, we first
> wanted to see:
>
> 1) If there was any fundamental objection to this idea before even the
> details are spelled out
>
> 2) If anyone is already working on this issue.
>
> 3) If anyone would like to join us.
>
>
> We are thinking that our general approach will be:
>
> 1) Use data from this source:
> https://biamaps.doi.gov/dataDownload/index.htmlIt has a compatible
> license, but will verify and document as part of this process.
>
> 2) Somehow allow mappers to "check out" a particular reservation's
> boundary.  Exact mechanism is TBD.
>
> 3) A human mapper will examine each boundary individually
>
> 4) Where OSM does not have a corresponding reservation boundary, the
> mapper will import the boundary into OSM (not sure of the exact mechanics
> at this time).  If the boundary needs to participate in a boundary
> relation, that will be handled here. Tag mapping is TBD at this point.
> Any conflicts with existing OSM features will be addressed in this step.
>
> 5) Where OSM has a boundary and it does not match the above source, and it
> has not been edited by a human mapper, proceed as in 4 above, except only
> replace geometry and preserve the history of the existing OSM features.
>
> 6) Where OSM has a boundary and it does not match our source, but it has
> been edited by a human mapper, use additional sources, including tribal
> sources, and county sources, to determine the true boundary and make
> necessary edits in OSM.  Deference will be given to the edits made by local
> mappers.
>
> To be determined:
> We are aware of some cases where different government bodies (e.g. Federal
> Government vs. a state government) dispute the extent of a reservation.
>
> Long term we would like to involve Native Americans, particularly youth
> living on reservations, in adding additional details to OSM about
> reservations, such as street names, amenities, etc., but we don't envision
> this as part of this import/organized effort process.
>
> We look forward to your initial feedback on this preliminary concept.
>
> Mike
>
>
> [1] Village Earth is a 501(c)(3) nonprofit organization that has worked in
> Indian Country for over 20 years and works closely with the Indian Land
> Tenure Foundation
> [2] David works for Village Earth
> [3] Most people on this list are probably familiar with Paul, a long time
> contributor to OSM
> [4] My OSM user name is tekim, I have been mapping in OSM since 2009.
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] City of Portsmouth, Virginia Building/Address Import

[Jonah Adkins]

Hi Pierre, Thanks for taking a look.

The source data for this import is not AI derived - the state GIS office (VGIN) 
collects datasets from each city/county in Virginia, then processes them into a 
statewide dataset that is released (with a OSM compatible license) on a 
quarterly basis.

Was there a particular area in the full or sample OSM files that looked bad?

Thx
-Jonah

> On Jun 15, 2019, at 5:06 PM, Pierre Béland  wrote:
> 
> Hi
> Jonah 
> 
> Footprints derived from AI Tools often have difficulty to interpret imagery 
> in particular where there are obstacles such as trees. This seems to be the 
> case here.  Do you have any plan to evaluate the accuracy of footprints and 
> correction to make if necessary?
> 
> Pierre 
> 
> 
> Le jeudi 13 juin 2019 23 h 57 min 04 s UTC−4, Jonah Adkins 
>  a écrit :
> 
> 
> Hey OSM, 
> 
> I'd like to propose an import of GIS data for Portsmouth, Virginia. The 
> source data is provided by the State of Virginia via the Virginia Geographic 
> Information Network (VGIN) under a  compatible license for import. There’s 
> around 49,000 buildings, most of which include an address and building type. 
> This import has been discussed on the OSM Slack Virginia channel with 
> pre-review of the available sample data and I anticipate local mapper support 
> with the import process. Conflation with existing OSM data will happen during 
> the import.
> 
> For more information and a sample OSM file, see: 
> 
> Github -> https://github.com/jonahadkins/portsmouth-osm-imports 
> 
> Wiki -> 
> https://wiki.openstreetmap.org/wiki/City_of_Portsmouth_Buildings/Address_Import
>  
> 
> 
> 
> This message has been cross-posted in Talk-US, Imports-US, & Imports. 
> 
> Also please rememberer SOTMUS is around the corner - talks, scholarships and 
> more! -> https://2019.stateofthemap.us 
> 
> Thanks, 
> 
> Jonah 
> jonahadkins.com
> ___
> Imports mailing list
> impo...@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/imports 
> 

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

Re: [Talk-us] [Imports] Grand Junction, CO Fire Hydrant Import

[Andrew]

Just a quick thought, but have you checked out the Conflation plug-in in
JOSM? Assuming the hydrant number that will go in your ref tag is unique,
that would be an easy way to match or use a search radius on already mapped
hydrants and then merge tags.

The only other issue I could see is that you'll probably need to check how
closely the hydrant locations jive with OSM data. In other words, is the
precise location of the fire hydrant important, or its relative location
from a nearby street/building/landmark in OSM?

Your city data may be extremely precise and is likely based on a local
coordinate reference system (CRS), whereas data in OSM may have been
armchair mapped from different imagery with good or poor alignment over
time (and uses WGS84). Depending on the quality of both datasets,
reprojecting may solve some of the issues but you may have to do some
manual review starting out.

-Andrew

On Thu, Nov 15, 2018, 8:00 AM  I am in the process of talking to my local city GIS office about
> importing their fire hydrant dataset. I will then (probably) expand to
> the other municipalities in my area, and then stop there.
>
> One of their concerns is keeping the data on OSM up to date.
>
> I'll be talking to them on Friday, November 16th, 2018.
>
> Tags that are user visible on their arcgis application and probable
> relevant tags in OSM:
> Hydrant Number => ref
> Test Date => check_date, operational_status:date, or survey:date
> Pressure - Static/Residual => fire_hydrant:pressure (maybe add a new
> tags for difference in static/residual pressures?)
> Flow Rate => flow_rate (probably), possibly use fire:hydrant:awwa_class
> Flow at 20 PSI => No tagging scheme for this yet. Maybe add a new tag
> for that, like flow_rate:?
> Model Number => model (maybe add manufacturer as well)
> Owner => operator (probably change CITY to "City of Grand Junction, CO"
> or similar)
> Route Number => I have no clue what this is for
>
> Tags that I intend to add either manually or through using the model
> number:
> fire_hydrant:diameter
> couplings
> couplings:type
> couplings:diameters
> pillar:type
> water_source
> wrench, cap:wrench (currently under discussion on OpenStreetMap wiki)
>
>
> Advantages of an import:
> Data comes from an official source and is unlikely to be outdated
> I don't have to map every fire hydrant manually
>
> Disadvantages of an import
> May conflict with some of my fire hydrant edits.
> Assumption that the dataset is complete (it isn't, but it is close)
>
> When running the import, I intend to do the following:
> 1) Do a download via overpass of fire hydrants
> 2) Using hydrants that I know exist in their dataset and OSM, write a
> validation rule to ensure that no two hydrants are closer than 10
> feet/3 meters (assuming it is possible to do that using
> validator.mapcss rules)
> 3) Write validation rules to automagically add additional information
> to the fire hydrants, based off of spec sheets
>
> Somewhere in there, mess around with osmsync in order to enable easier
> updating of the data.
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] [Imports-us] Spartanburg County SC road centerlines import

[Mike N]

On 10/22/2018 2:56 PM, Rory McCann wrote:

Hi Mike.

Thanks for the answers, that clears things up. Bt

On 10/22/2018 5:00 AM, Rory McCann wrote: >> I'm a little unclear 
about one big question: What are you doing with
the existing data in OSM? Existing OSM data seems to have nearly 
identical locations to this new data. You're just going to update 
existing OSM data? Do you know how much existing OSM data needs to be 
updated?


   All existing data will be reviewed.   Most of it will add the 
surface attribute and lanes if visible from imagery and remove the 
tiger:reviewed attribute.   So nearly everything will be modified.


I'm sorry, maybe I'm having a brain fart, but I'm still confused. It
sounds like you're going to look at all existing OSM roads in that
county and manually review them? Just going through and fixing them up
and removing tiger:* tags, and keeping the existing roads in OSM? That
sounds great. But that's a regular map-a-thon, not an import. What do
you need this new data for? If I'm reading you right, this new data from
the county won't be used at all? Right?

You're not going to *replace* the existing OSM data with this new data, 
right? You're not going to delete the existing OSM data, right?


If you (& friends) are going to fix up the roads, you don't need to talk
to this list. Just go ahead and do it! That's not an import. Just 
tracing from the imagery you created from this data isn't an import. 
That's just using a new imagery source. You can just go ahead and do that.


If you want to find new roads that aren't in OSM, load OSM & this new 
data into postgres, and look for roads in the new dataset that are far 
(>10m?) from anything in OSM. Should be quicker than humans looking at 
all.  (Do you know how to do that?)


  There will be 50 to 200 streets of new data used for new 
subdivisions.  I suppose that I could have created sets of data for 
"These might be renamed",  "These might be imported" , "These might be 
adjusted" , "These might be deleted" (Because a diff doesn't identify 
which one is right) , then not bothered to mention the additional review 
which would indeed just be a local project.


  If this is deemed not to be an import, then we will begin immediately.

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

Re: [Talk-us] [Imports-us] Spartanburg County SC road centerlines import

[Mike N]

Thank you for your comments.  Answers inline.

On 10/22/2018 5:00 AM, Rory McCann wrote:

On 22/10/2018 05:20, Mike N wrote:
This is a proposed import of road centerlines for Spartanburg County 
SC, based on county GIS data.   This will include a systematic review 
of all roads in the county and qualify to remove tiger:reviewed tags.


https://wiki.openstreetmap.org/wiki/Spartanburg_county_road_center_line_import 



A roads import! 

There's a few lanes that are weird. lanes=7 for a 6 lane road. It's 
weird that some roads have lanes on some parts, not all (e.g. "Hollywood 
Street"). Maybe try to make it consistant? JOSM validator has found a 
handful of topology errors. There's ~100 examples of roads that aren't 
connected properly (nodes on top of each other, but not connected).


You seem to be defaulting to "highway=residential" a lot (e.g. if you 
dohn;t know another, or turning 'Gravel' into 'highway=residential 
surface=gravel'). I don't know a lot about tagging in the USA, but isn't 
there (wasn't there) some problem with the TIGER data using residential 
too much?


  The 'lanes' and highway type were experimental to see what useful 
information could be mined from the source data.   I agree that they are 
all but useless for OSM's purpose.  95% of the work will be checking for 
geometric alignment and name from the background image layer in the 
editor.   For example there have been many projects where sharp 
intersections have been realigned for safety to create right angles. 
And streets have been renamed for E911 purposes.


   The one case where I see direct access to converted data is a new 
residential subdivision - where a new group of roads would be copied 
from the reference data and connected to existing data.   Those would 
nearly all be residential.  So I didn't take the time to go back and 
remove lane attributes from the raw data.


   Defaulting to residential was not totally wrong for this county in 
the same way it was wrong out west.  The most likely mismatch would be a 
new unclassified road into an industrial area - but those will likely be 
single roads, and thus be as easy to hand trace and assign the correct 
classification as to copy from the reference layer.


Can you link to your discussion with the local community, how/where did 
that happen?


  This was mostly verbal discussion with another community member, as 
well as one of the meetups at 
https://www.meetup.com/Open-Street-Map-upstate/ , and using some of the 
ideas presented by Clifford Snow in his "Discover Rural America" 
presentation at https://www.youtube.com/watch?v=EoX2Q2aJXQE=1211s .



The link the tasking manager project doesn't work.


   Corrected.

I'm a little unclear about one big question: What are you doing with the 
existing data in OSM? Existing OSM data seems to have nearly identical 
locations to this new data. You're just going to update existing OSM 
data? Do you know how much existing OSM data needs to be updated?


  All existing data will be reviewed.   Most of it will add the surface 
attribute and lanes if visible from imagery and remove the 
tiger:reviewed attribute.   So nearly everything will be modified.


   Stepping back to the big picture - although many hours have been 
spent improving the road network in that county, OSM is the last source 
I would use when planning a trip to an unfamiliar part of the county. 
There have been other US projects in which a group would go into a "fast 
growing region" and review all roads, adding surface and lane attributes 
to improve navigation.   The end goal of this project is similar.   When 
combined with some additional planned work such as address points, OSM 
will be suitable as the primary reference source when planning a trip 
through that county.


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

Re: [Talk-us] [Imports] Bing Building Import

[Andrew]

Hi all-

Have there been any ideas about how we want to handle the import process?

My thoughts are that this could be treated as a unified project for
"simple" imports that will not be conflating the footprints with other data
(e.g. address points).  My thought is we could adopt a streamlined process
like this to avoid filling up the imports lists when the experience of the
mapper needs to be reviewed rather than the actual import process itself:

   1. Write a project-level wiki page with standard instructions and tips
   with community feedback
   2. Have a table on the page (and maybe the Import Catalog) for local
   groups or users that would like to "claim" the import in a certain area and
   track import/validation progress.
   3. Get a few volunteers from the community who can serve as "project
   managers" to offer guidance and validation
   4. When a new user starts the import process, they complete a small test
   area and then message a project manager to get thumbs up and feedback
   before continuing on with the import
   5. We all use a special #bingbuildings changeset hashtag so that we can
   monitor and track progress
   6. Optionally, set up a project in the OSM-US tasking manager when the
   import is complete for validation purposes by the community at-large.

If someone is running an import that conflates the footprints with other
datasets (e.g. address points), that would go through the normal community
review process since we'll have a separate license and process to review.

Thanks,

Andrew

On Wed, Jul 4, 2018 at 12:32 PM Greg Morgan  wrote:

>
>
> On Wed, Jul 4, 2018 at 1:34 AM, Christoph Hormann  wrote:
>
>>
>> Greg,
>>
>> I will comment on a few of the new things you have written but like to
>> emphasize this is still not an import review because a lot of
>> information required for that is missing.  You could however read up
>> old discussions on previous building imports here to get an idea on the
>
> requirements and suggestions made for those.
>>
>
> Got it.  It is not a review but a helpful number of ideas.  Thank you for
> your time.
>
>
>> > [...]  In my early opinion, the foot prints are no
>> > better nor no worse than a craft mapper,s drawing
>>
>
>
>
>> This is always a pretty meaningless comparison because it is apples and
>> peaches.  When i talk about "quality aspects" i mean quantifiable
>> measures of quality.
>>
>> > [...]  As your
>> > other post provided an idea of starting with Montana, that will not
>> > be useful in my case.
>>
>> I suggested rural Montana might be a good place to start if you
>> intend "to poke the data for quality issues".  Since that is not what
>> you want to do my suggestion is pretty useless for you obviously.
>>
>> > > Microsoft's process documentation contains a number of hints that
>> > > indicate things can go wrong in the process in ways that are likely
>> > > to produce significant errors of kinds that are very unlikely to
>> > > happen in manual mapping.  Without having reliable data on how
>> > > often these things do happen (and how this varies between different
>> > > geographic settings) you would essentially be doing a blind import.
>> >
>>
>
> Christoph, as an analogy you have read that you can get sun burnt if you
> go outside.  Now you are afraid to go outside because you read about the
> resulting skin cancer. Microsoft is just saying that the data us good but
> use at your own risk.  They also point out that we should go through the
> import process.  Keeping up with the analogy, I have been sun burnt in
> Montana, Wyoming, Utah, Colorado, California, and Arizona for sure.  There
> are other states where I have been sun burnt but they are too numerous to
> list.  My point is that I understand what is rural America in all the
> states listed.  The sample I have provided so far is in rural Arizona.  It
> is not in metro Phoenix.  I can parse Montana but that would not add any
> any more detail to this discussion.  The test.osm file here is rural
> America but in Arizona by the border with Mexico.  People who live in this
> area are either retires or work for the border patrol.
> https://drive.google.com/open?id=1I7BPMKLgABk8ikUdEPFpl6zKgh9E-sDN
>
>
>
>> > Depending on the craft mapper, hand drawn buildings can have the same
>> > problems. [...]
>>
>> As i have been very clear about this is not the case:
>>
>> > > Microsoft's process documentation contains a number of hints that
>> > > indicate things can go wrong in the process in ways that are likely
>> > > to produce significant errors of kinds that are very unlikely to
>> > > happen in manual mapping.
>>
>> The only thing that could convince me to change this assessment would
>> be - as already mentioned - a thorough analysis of the quality that
>> holds up to scientific scrutiny.  And it is frankly much more likely
>> that such analysis would confirm my impression.  If it does not that
>> would mean Microsoft has made progress in the field that absolutely
>> 

Re: [Talk-us] [Imports] Durham and Chatham County Address Imports (North Carolina, USA)

[James Umbanhowar]

Point taken.  In this case, they are the center of property polygons,
so not on buildings, conflated with buildings nor at entrances.  I
don't mind if they are reasonably placed as nodes, but these are not
quite there, yet.

James
On Sat, 2018-07-21 at 15:34 -0400, Nathan Mills wrote:
> To the extent that the address points are not duplicates of existing
> address nodes, unconflated address nodes are a perfectly legitimate
> means of mapping and do not need to be "fixed." Even if the address
> exists on a poly, it's still fine as long as the node is marking
> something meaningful, like the front door of the building. Some have
> in the past gone so far to say that nodes are preferable since it
> allows routers for the differently abled to provide door-to-door
> guidance.
> 
> -Nathan
> 
> 
> On July 21, 2018 2:39:36 PM EDT, James Umbanhowar  > wrote:
> > Sorry, I just saw this.  Please do not upload this, yet.  You have
> > not
> > responded to any of the feedback that I have given.  Instead you
> > have
> > chosen to just upload all the points into the database and then
> > correct
> > the database afterwards.
> > 
> > Please, instead, break this into smaller areas and then conflate
> > the
> > points with existing objects and then upload. From what I can tell,
> > this would be easiest done with the Tasking Manager.
> > 
> > Also, I have already signalled my willingness to help with this
> > task
> > and using the tasking manager would allow me and possibly others to
> > help.
> > 
> > Thank you,
> > 
> > James
> > 
> > 
> > 
> > On Thu, 2018-07-19 at 23:42 -0400, Leif Rasmussen wrote:
> > >  Hi everyone!
> > I have finally verified the license on the Chatham
> > >  County, NC address data which includes about 44,000 address
> > > points. 
> > >  It is public domain except for that it has a "no direct resale"
> > >  policy that allows indirect resale (includes other data), which
> > > is
> > >  compatible with OSM.  Durham County, which uses the ODbL has
> > > also
> > >  produced address data.  I will be completing both the imports
> > > this
> > >  weekend.  Some discussion has taken place about adding buildings
> > > in
> > >  Durham at the same time as the import, but to keep everything
> > > more
> > >  simple, I have decided on just adding nodes for now and then
> > > merging
> > >  with buildings later.  This would reduce complexity and help
> > >  everything run more smoothly.  I will upload all of the data
> > > alone. 
> > >  This helps keep everything more simple, leading to fewer
> > > mistakes.  I
> > >  do not see very much benefit to having several account all
> > > importing
> > >  the data.
> > 
> > Details:
> > Size of both imports combined: 190,000 addresses
> > Date of upload: Saterday and Sunday, 21st and 22nd of July, 2018
> > Type of import:  One time with JOSM in 20 changesets.
> > Account:  LeifRasmussen_import
> > 
> > Wiki pages:
> > Durham County
> > Chatham County
> > 
> > Please let me know of any concerns of ideas!  I would love to
> > improve
> > the import as much as I can.
> > Thanks!
> > Leif Rasmussen
> > 
> > 
> > Imports mailing list
> > impo...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/imports
> 
> 

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

Re: [Talk-us] [Imports] Durham and Chatham County Address Imports (North Carolina, USA)

[Nathan Mills]

To the extent that the address points are not duplicates of existing address 
nodes, unconflated address nodes are a perfectly legitimate means of mapping 
and do not need to be "fixed." Even if the address exists on a poly, it's still 
fine as long as the node is marking something meaningful, like the front door 
of the building. Some have in the past gone so far to say that nodes are 
preferable since it allows routers for the differently abled to provide 
door-to-door guidance.

-Nathan


On July 21, 2018 2:39:36 PM EDT, James Umbanhowar  wrote:
>Sorry, I just saw this.  Please do not upload this, yet.  You have not
>responded to any of the feedback that I have given.  Instead you have
>chosen to just upload all the points into the database and then correct
>the database afterwards.
>
>Please, instead, break this into smaller areas and then conflate the
>points with existing objects and then upload. From what I can tell,
>this would be easiest done with the Tasking Manager.
>
>Also, I have already signalled my willingness to help with this task
>and using the tasking manager would allow me and possibly others to
>help.
>
>Thank you,
>
>James
>
>
>
>On Thu, 2018-07-19 at 23:42 -0400, Leif Rasmussen wrote:
>> Hi everyone!
>I have finally verified the license on the Chatham
>> County, NC address data which includes about 44,000 address points. 
>> It is public domain except for that it has a "no direct resale"
>> policy that allows indirect resale (includes other data), which is
>> compatible with OSM.  Durham County, which uses the ODbL has also
>> produced address data.  I will be completing both the imports this
>> weekend.  Some discussion has taken place about adding buildings in
>> Durham at the same time as the import, but to keep everything more
>> simple, I have decided on just adding nodes for now and then merging
>> with buildings later.  This would reduce complexity and help
>> everything run more smoothly.  I will upload all of the data alone. 
>> This helps keep everything more simple, leading to fewer mistakes.  I
>> do not see very much benefit to having several account all importing
>> the data.
>
>Details:
>Size of both imports combined: 190,000 addresses
>Date of upload: Saterday and Sunday, 21st and 22nd of July, 2018
>Type of import:  One time with JOSM in 20 changesets.
>Account:  LeifRasmussen_import
>
>Wiki pages:
>Durham County
>Chatham County
>
>Please let me know of any concerns of ideas!  I would love to improve
>the import as much as I can.
>Thanks!
>Leif Rasmussen
>
>___
>Imports mailing list
>impo...@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/imports

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Bing Building Import

[Kevin Kenny]

The damage done by the "foot shot" is the damage
to the community. At least one researcher found a way to
study this (because of inadvertent import quality issues with
TIGER) and found that the areas with better import quality
wound up more poorly mapped over time. I'm convinced that
there are several confounding effects in play here, so
I don't take the results as more than a strong caution.

It doesn't stop me from importing, but it holds me back from
a number of things. I have a number of state and local databases
available with hydrography, transportation networks, recreational
trails, and so on, that I use as sources for "what's missing from
the map" but would now never contemplate importing wholesale.
(Once in a while, if they're substantially correct, I'll copy-and-paste
an object or two - lawfully.) I confine my imports to things
such as the boundaries of large parks and wilderness areas
that are of public interest but infeasible to field map.
Even the agencies that run them grapple with ancient
inaccurate surveys.

I will confess that I, too, have been remiss in picking up
after the TIGER. My mapping concentrates on where I go:
my own neighbourhood, and less-popular recreational
destinations for which no good maps (public or commercial)
exist at all.I might have done more about the highway
network if TIGER weren't "almost but not quite good enough",
so I may personally be an example of the damage
that particular import has done to the community.

I have few if any qualms about doing a quick copy-and-paste
of something like a pond outline from a public source
if a manual review confirms that it's correct. That's
a shortcut around the tedium of tracing around
orthophotos, and I can't see that doing it on a scale
of individual features does any real harm - it's just
a labor-saving technique. and likely to give better
results than tracing with my hand tremor.

And now I'm going back to curating data - doing the
necessary conflation to reimport updated protected area
polygons from New York State - demonstrating that
imported data don't have to be 'dead'.

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

Re: [Talk-us] [Imports-us] Importing Addresses in Orange County North Carolina

[Clifford Snow]

On Sat, Jun 23, 2018 at 2:50 PM Greg Morgan  wrote:

>
>
> On Wed, Jun 20, 2018, 2:34 PM Clifford Snow 
> wrote:
>
>> A couple of things  First you have two tags that are not needed,
>> addr:state and  addr:country.
>>
> I have a different opinion on this subject. I always add these two tags.
> We are an international map. If he has the data already, I don't see why
> they shouldn't be added. My view is shaped by living in a border state.
>

Greg - I don't have strong feelings one way or another, but since this is
spatial data, it's easy to figure out the state and country. City not so
much,  Often it's a postal city code even though the location is in
unincorporated areas. But like you I do sometimes look at the tiger tags on
a way to see which county it's in.

Best,
Clifford


-- 
@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

Re: [Talk-us] [Imports-us] Importing Addresses in Orange County North Carolina

[Greg Morgan]

On Sat, Jun 23, 2018 at 2:57 PM, Tommy Bruce  wrote:

> I agree I don't see anything wrong with keeping the state and country tag.
>
> 2018-06-23 14:50 GMT-07:00 Greg Morgan :
>
>>
>>
>> On Wed, Jun 20, 2018, 2:34 PM Clifford Snow 
>> wrote:
>>
>>> A couple of things  First you have two tags that are not needed,
>>> addr:state and  addr:country.
>>>
>> I have a different opinion on this subject. I always add these two tags.
>> We are an international map. If he has the data already, I don't see why
>> they shouldn't be added. My view is shaped by living in a border state.
>>
>
I forgot to mention that these tags where handy when an influx of seo spam
hit my area.  There was no second thought about deleting the spam when
there were Washington, South Carolina, and what not in the seo spam
addresses.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports-us] Importing Addresses in Orange County North Carolina

[Greg Morgan]

On Wed, Jun 20, 2018, 2:34 PM Clifford Snow  wrote:

> A couple of things  First you have two tags that are not needed,
> addr:state and  addr:country.
>
I have a different opinion on this subject. I always add these two tags. We
are an international map. If he has the data already, I don't see why they
shouldn't be added. My view is shaped by living in a border state.

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

Re: [Talk-us] [Imports-us] Importing Addresses in Orange County North Carolina

[Leif Rasmussen]

Hi Tommy,
Yes, I agree that existing addresses should be kept. When I wrote that I
removed duplicates, what I actually meant was that I removed duplicates of
existing addresses from the addresses that I am planning to add.  That is
to say that only missing addresses will be added.  Sorry about being
unclear.
Thanks!
Leif

On Fri, Jun 22, 2018, 7:06 PM Tommy Bruce  wrote:

> I feel like addresses that are already on the map should be kept or
> combined in some way.
>
> If addresses are in place than someone with local knowledge added those
> addresses.
>
> 2018-06-20 14:33 GMT-07:00 Clifford Snow :
>
>> A couple of things  First you have two tags that are not needed,
>> addr:state and  addr:country.
>>
>> The other is a question on how you plan to conflate address? A quick
>> glance showed that some of the new address nodes are a few meters away from
>> the building polygon - with an address. With a large import - it could be
>> hard to catch.
>>
>> Best,
>> Clifford
>>
>> On Wed, Jun 20, 2018 at 8:46 AM Leif Rasmussen <354...@gmail.com> wrote:
>>
>>> Hi everyone,
>>> I am planning to import addresses in Orange County North Carolina.  I
>>> have already completed all data transformation and duplicate removal
>>> necessary and I would like advice on importing the addresses.  This is my
>>> first import, and I would like to avoid messing up the OSM database and
>>> having to revert.  The data set that I plan to import includes about 74,000
>>> addresses.  My plan is to upload 11 small chunks between 5,000 and 9,000
>>> addresses over the course of a day (hopefully July 1st if all runs
>>> smoothly).
>>> The processed addresses are available for download here
>>>  (all
>>> duplicates of existing addresses have been removed).
>>> If addresses are not wanted for any reason, please let me know!  I am
>>> open to discussing the import.  Also, I need as much information from
>>> experienced mappers as possible to avoid screwing up.  If anyone else has
>>> attempted an address import and made any mistakes at all (or done anything
>>> well), please let me know!
>>> Thank you,
>>> Leif Rasmussen
>>>
>>> My OSM acount is LeifRasmussen
>>> .
>>> My Import acount is  LeifRasmussen_import
>>> .
>>> The import wiki page
>>> 
>>>  has
>>> been created as well.
>>> ___
>>> Imports-us mailing list
>>> imports...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/imports-us
>>>
>>
>>
>> --
>> @osm_seattle
>> osm_seattle.snowandsnow.us
>> OpenStreetMap: Maps with a human touch
>>
>> ___
>> Imports-us mailing list
>> imports...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports-us
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] US Sports Fields Import

[Jubal Harpster]

Hi Jason,

I mentioned this in your repo but thought I would also mention it to this list. 
The Microsoft legal team reviewed this particular scenario and determined that 
it is consistent with the current terms of the imagery as it relates to 
contributing to OSM.  You're welcome to use the Bing imagery as an input to 
this process.

Regards,
-Jubal 
https://www.openstreetmap.org/user/jharpster


-Original Message-
From: Jason Remillard [mailto:remillard.ja...@gmail.com] 
Sent: Tuesday, January 2, 2018 7:22 PM
To: Rory McCann 
Cc: Imports OpenStreetMap.org ; 
talk-us@openstreetmap.org Openstreetmap 
Subject: Re: [Imports] [Talk-us] US Sports Fields Import

Hello,

Before I started this project in November I contacted the Bing licensing group, 
described my intentions, and asked for a developer key. They responded by 
giving me instructions on how to get a developer key.

I imagine they don't get many requests like this and it turns out they didn't 
understand what I was asking them. Today I was contacted by Microsoft with the 
news that they are not sure if the upstream licenses they have with the 
satellite image vendors allows them to grant OSM permission to do this kind of 
project.

The good news is that they indicated that they are going to try to grant 
permission for this use case for OSM. The issue has been escalated into the 
legal team at MS.

I am sure Microsoft will communicate with us when they decide what to do, until 
then we have to wait.

Jason

On Tue, Jan 2, 2018 at 8:30 AM, Rory McCann  wrote:
> Hi,
>
> This is very interesting! And it's great to see some source code. I'd 
> be tempted to try this myself on things I'm interested in.
>
> You mentioned that Microsoft has given permission for this, is that 
> just for your one specific thing, or can any OSMer run this on their area?
> Can you post the documentation with the permission?
>
> Since you're importing the resultant file into OSM, this isn't really 
> relevant, but you say "The two final output files are in the public 
> domain.". Surely these output files are basically derived from 
> existing OSM data, and would be under the ODbL?
>
> I haven't looked at your data, or tried to run the code myself, but 
> I'd like to do it sometime.
>
> Rory
>
> On 30/12/17 20:51, Jason Remillard wrote:
>> Hi,
>>
>> I have trained a neural network to find baseball, basketball, and 
>> baseball fields in satellite images. It was trained using OSM and 
>> bing tiles. Using the neural network I have mapped 2,800 new fields 
>> in the US northeast, I would like to import the missing fields back into OSM.
>>
>> Wiki project page :
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki
>> .openstreetmap.org%2Fwiki%2FUS_Sports_Fields_Import_2018=02%7C01
>> %7Cjubalh%40microsoft.com%7C376ab405aa48495df45708d552595531%7C72f988
>> bf86f141af91ab2d7cd011db47%7C1%7C0%7C636505465998805392=Z3e%2F7
>> g1acUuWldXlhjwvVxQu2h%2FxthzMM1OpSasPBkc%3D=0
>> Github: 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> ub.com%2Fjremillard%2Fimages-to-osm=02%7C01%7Cjubalh%40microsoft
>> .com%7C376ab405aa48495df45708d552595531%7C72f988bf86f141af91ab2d7cd01
>> 1db47%7C1%7C0%7C636505465998805392=%2BWtB2k7S97MZwro3Taqaw744ew
>> 31UUcQXpHqxDr4mwI%3D=0
>>
>> Details
>>
>> In November of 2017 all of the mapped baseball, basketball, and 
>> tennis courts in Massachusetts, New York, Connecticut, Rhode Island, 
>> and Pennsylvania were used to train a neural network.
>>
>> The import data was created by
>>
>> Running the neural network over the training Bing satellite images to 
>> identify the missing sports fields from OSM. Fields found by the 
>> network but not in OSM are passed to the next step.
>>
>> A visual QA script shows the newly mapped features over the Bing 
>> satellite images, the user approves or rejects the edits. I rejected 
>> any way that wasn't an excellent match to the satellite images.
>>
>> The final OSM files are created from the ways selected by myself in 
>> the visual QA script.
>>
>> The ways are tagged with leisure=pitch, plus the sport=* tag.
>>
>> The changeset tags will be comment="Imported data, phase 1, 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki
>> .openstreetmap.org%2Fwiki%2FUS_Sports_Fields_Import_2018=02%7C01
>> %7Cjubalh%40microsoft.com%7C376ab405aa48495df45708d552595531%7C72f988
>> bf86f141af91ab2d7cd011db47%7C1%7C0%7C636505465998805392=Z3e%2F7
>> g1acUuWldXlhjwvVxQu2h%2FxthzMM1OpSasPBkc%3D=0", and 
>> source="Bing", import=yes
>>
>> The jremillard-import account will be used to upload the 2 osm files.
>> The OSM files are already split to be under the 10,000 item limit on 
>> a changeset. They will be uploaded with josm.
>>
>> Prior to starting the project I emailed Microsoft bing licensing 
>> group describing the project and received approval to use the Bing 

Re: [Talk-us] [Imports-us] New to lists and would like to suggest some imports

[Richard Welty]

first things first. the import guidelines are here:

https://wiki.openstreetmap.org/wiki/Import/Guidelines

second, the licensing is critical. make absolutely sure that the state
has a clear statement
of public domain, CC0 or equivalent license.

probably the most valuable import would be conflated address points and
building footprints.
NYC did such an import, and Mass as well. they have import pages that
are worth looking over.
Jason Remillard has tools from the Mass project here:

https://github.com/jremillard/osm-import-toolkit

you can use the import-us mailing list to kick things around and discuss
what you're
trying to do. you need to prepare a page describing your import proposal
and it will
eventually have to be brought to the import mailing list for review. the
better the job
you do before going to the import list, the better off everyone will be.

i'm currently developing a plan for a NYS address points import
(hopefully with building
footprints) and so i'm in a somewhat similar place right now.

richard

On 1/8/18 7:54 PM, Russell Meier wrote:
>
> Greetings,
>
>  
>
> I am new to the idea of discussing additions to OSM and like to do my
> best to follow best practices in suggesting an import. I am not sure
> were to start.
>
>  
>
> I live in Tennessee USA. The State of Tennessee has posted a number of
> datasets without any license restrictions on this site
> tn-tnmap.opendata.arcgis.com . I would like to suggest some of this
> data would be useful in open street maps. For now I would like to add
> a building outline data set to OSM and a state parks trails data set.
>
>  
>
> As I am new to the idea of putting up data for discussion before it is
> added to OSM I am not sure what information would be best to include
> to begin a discussion/ review process. I would appreciate some
> suggestions advice as to what information to include in this
> suggestion / request for review.
>
>  
>
> Thanks,
>
>  
>
> Treldin
>
> (Russell Meier)
>
>  
>
> Sent from Mail  for
> Windows 10
>
>  
>
>  
>
>
>
> ___
> Imports-us mailing list
> imports...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports-us


-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search



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

Re: [Talk-us] [Imports] Integrating our open source data into OSM

[Rihards]

On 2017.11.10. 00:11, Sean Lindsey wrote:
> It seems that it's going to be hard to come up with a mass import
> solution that every one can agree on. I would suggest that you take
> name, address, phone number, website and category then try and
> re-geocode the data, but it seems there is opposition to this method as
> well.
> 
> Another approach - as a way of keeping OSM and this data separate - is
> having this POI data be a "secondary resource" that OSM users could "opt
> in" to adding into their mapping set, but not be inherently owned or in
> OSM's primary data set. For example, by loading up an OSM database you
> could be linked to us or someone who creates a derivative of our data
> suitable for importing into OSM maps. Thereby OSM does not feel
> responsible for this resource but it still becomes available for people
> to import and use via us or someone else. In this case we would want to
> work with someone in order to create an OSM import-friendly version of
> this data. We have a ton of indicators that tell us the quality and
> freshness of this data and potentially we can rework in into something
> more usable.

as opposed to some other data (public transportation timetables and
similar), this information belongs in osm - the concern is not about it
being there, the concern is about licensing and accuracy, both being
discussed and clarified.
accuracy issue can be handled by a layer that looks for features in this
dataset that cannot be matched to existing osm features. sort of map
notes, although flooding notes with this might not be feasible.
osm community response, after a survey, could be to add the entity, add
it with corrections (location etc) or reject it as not existing on the
ground - it might be useful to get a feedback loop for those.

feedback amount will vary a lot. i'd expect smaller towns and the like
not to get much feedback at all. suggesting a layer like this to be
used. any pois without any feedback in 6 months to be imported (split in
smaller sections and all other usual precautions).
this would not be a blanked import and would be expected to be "better
than before".

> Thoughts?
> 
> On Thu, Nov 9, 2017 at 1:09 AM, Rory McCann  > wrote:
> 
> Hi Sean,
> 
> On 09/11/17 07:14, Sean Lindsey wrote:
> > Thanks for all the feedback, we have put together some blogs to help
> > people figure out how to play with the data, to give people an idea of
> > what it is and how it was put together.
> >
> > https://blog.cybo.com/
> 
> So that website says:
> 
> OmniPlaces is formed from billions of records (literally), from
> tens of thousands of sources (literally)
> 
> 
> Trying to figure out the licence for tens of thousands of datasets is
> practically impossible Licence issues are often a problem with
> imports, and I think this could be a show-stopper for this.
> 
> On 09/11/17 05:54, Jo wrote:
> 
> If the addresses are in the data as well, we don't really need
> to use
> the lat/lon coordinates.
> 
> 
> Not necessarily, depends where the addresses came from. If you had
> lots of lat/longs, and geocoded the, and threw away the lat/longs
> then you don't have a clean dataset.
> 
> -- 
> Rory
> 
> 
> 
> ___
> Imports mailing list
> impo...@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/imports
> 
> 
> 
> 
> 
> -- 
> Sean Lindsey
> Cybo Company
> LinkedIn 
> 541-912-2505 
> 
> 
> ___
> 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

Re: [Talk-us] [Imports] Integrating our open source data into OSM

[Sean Lindsey]

It seems that it's going to be hard to come up with a mass import solution
that every one can agree on. I would suggest that you take name, address,
phone number, website and category then try and re-geocode the data, but it
seems there is opposition to this method as well.

Another approach - as a way of keeping OSM and this data separate - is
having this POI data be a "secondary resource" that OSM users could "opt
in" to adding into their mapping set, but not be inherently owned or in
OSM's primary data set. For example, by loading up an OSM database you
could be linked to us or someone who creates a derivative of our data
suitable for importing into OSM maps. Thereby OSM does not feel responsible
for this resource but it still becomes available for people to import and
use via us or someone else. In this case we would want to work with someone
in order to create an OSM import-friendly version of this data. We have a
ton of indicators that tell us the quality and freshness of this data and
potentially we can rework in into something more usable.

Thoughts?

On Thu, Nov 9, 2017 at 1:09 AM, Rory McCann  wrote:

> Hi Sean,
>
> On 09/11/17 07:14, Sean Lindsey wrote:
> > Thanks for all the feedback, we have put together some blogs to help
> > people figure out how to play with the data, to give people an idea of
> > what it is and how it was put together.
> >
> > https://blog.cybo.com/
>
> So that website says:
>
> OmniPlaces is formed from billions of records (literally), from tens of
>> thousands of sources (literally)
>>
>
> Trying to figure out the licence for tens of thousands of datasets is
> practically impossible Licence issues are often a problem with
> imports, and I think this could be a show-stopper for this.
>
> On 09/11/17 05:54, Jo wrote:
>
>> If the addresses are in the data as well, we don't really need to use
>> the lat/lon coordinates.
>>
>
> Not necessarily, depends where the addresses came from. If you had lots of
> lat/longs, and geocoded the, and threw away the lat/longs then you don't
> have a clean dataset.
>
> --
> Rory
>
>
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>



-- 
Sean Lindsey
Cybo Company
LinkedIn 
541-912-2505 <(541)%20912-2505>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Integrating our open source data into OSM

[Sean Lindsey]

Thanks for all the feedback, we have put together some blogs to help people
figure out how to play with the data, to give people an idea of what it is
and how it was put together.

https://blog.cybo.com/

I assumed the set we released was not yet ready for OSM but with some
guidance I may be able to go back through and derive something that's more
useful for you and likely others interested in working with the data. Most
of our records/POIs are from several different sources, which means the way
a record is compiled could influence how useful it is.

On Wed, Nov 8, 2017 at 8:54 PM, Jo  wrote:

>  If the addresses are in the data as well, we don't really need to use the
> lat/lon coordinates. The best way to use this kind of data, is to use it as
> one of several sources. So a direct import is out of the question, but
> using it as a shortcut and combining with what we already have plus aerial
> imagery plus possibly an extra lookup in other sources could be considered.
>
> Of course, we don't want to be a front end for SEO techniques, so maybe
> the data needs to be pruned from overly commercial information and
> descriptions, before it is useful to us.
>
> I'm downloading it too, but it takes a while. I can probably figure out a
> way to convert it into something usable (at a technical level).
>
> Polyglot
>
> 2017-11-09 2:53 GMT+01:00 Brian May :
>
>> Its critical to know where the lat/longs came from. For example, if they
>> came from Google Maps - then its a no go, because Google's licensing is
>> incompatible with OSM. Their geocodes are not public domain, etc. Same
>> thing applies to many / most other commercial geocoding services. If you
>> don't know how the lat/longs were derived, then that is probably a show
>> stopper as well.
>>
>> Brian
>>
>>
>> On 11/8/2017 1:53 PM, Sean Lindsey wrote:
>>
>> We have open sourced our US POI data, it may not be ready for a direct
>> import into OSM, but we'd be willing to try to get it there.
>>
>> Its a national directory of 59 million US businesses, that has been
>> updated as of this summer. And should be getting another refresh shortly.
>>
>> What process is there to discuss and work to integrate this data?
>>
>> The data is available under a creative commons attribution license at
>> https://omniplaces.cybo.com/
>>
>> I would be willing to waive and/or clarify certain aspects of the licence
>> if needed however.
>> * I asked this same question in help.openstreetmap.org
>> ,
>> and was referred to these mailing lists
>>
>> Regards,
>> --
>> Sean Lindsey
>> Cybo Company
>> LinkedIn 
>> 541-912-2505 <(541)%20912-2505>
>>
>>
>> ___
>> Talk-us mailing 
>> listTalk-us@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>>
>


-- 
Sean Lindsey
Cybo Company
LinkedIn 
541-912-2505
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Integrating our open source data into OSM

[Mike Thompson]

I downloaded data for one of the states (Colorado) to attempt checkout its
quality.  It appears to be in JSON (not GeoJSON).  Is there an easy way to
get the data into something like QGIS so it can be visualized on a map?



On Wed, Nov 8, 2017 at 6:53 PM, Brian May  wrote:

> Its critical to know where the lat/longs came from. For example, if they
> came from Google Maps - then its a no go, because Google's licensing is
> incompatible with OSM. Their geocodes are not public domain, etc. Same
> thing applies to many / most other commercial geocoding services. If you
> don't know how the lat/longs were derived, then that is probably a show
> stopper as well.
>
> Brian
>
>
> On 11/8/2017 1:53 PM, Sean Lindsey wrote:
>
> We have open sourced our US POI data, it may not be ready for a direct
> import into OSM, but we'd be willing to try to get it there.
>
> Its a national directory of 59 million US businesses, that has been
> updated as of this summer. And should be getting another refresh shortly.
>
> What process is there to discuss and work to integrate this data?
>
> The data is available under a creative commons attribution license at
> https://omniplaces.cybo.com/
>
> I would be willing to waive and/or clarify certain aspects of the licence
> if needed however.
> * I asked this same question in help.openstreetmap.org
> ,
> and was referred to these mailing lists
>
> Regards,
> --
> Sean Lindsey
> Cybo Company
> LinkedIn 
> 541-912-2505 <(541)%20912-2505>
>
>
> ___
> Talk-us mailing 
> listTalk-us@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-us
>
>
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Fort Worth, Texas import

[Andrew Matheny]

Daniel-

Thanks for the heads up!

It looks like their footprints cover an area of the city that I've already
imported, but the height data would certainly be useful. I think it would
make sense to add this in to the import project.

Thanks!

Andrew Matheny

On Jun 21, 2017 11:56 PM, "Daniel O'Connor" 
wrote:

> Hi Andrew,
> With https://wiki.openstreetmap.org/wiki/Microsoft_Building_Footprint_Data
> also becoming available recently; any thoughts on (perhaps a separate
> project?) cross checking that against whats available in OSM in addition to
> the import here?
>
> Texas Lubbock, Longview,* part of Fort Worth*, Austin, downtown Houston,
> and Corpus Christi
>
> 236,466 buildings available
>
> On Sun, May 28, 2017 at 3:39 AM,  wrote:
>
>> Andrew,
>>
>>
>>
>> Looks good to me and a great follow up to the Dallas project.  I would
>> suggest contacting the project lead for project 95, they appear to work at
>> mapbox.  I contacted the mapbox user that created a digitizing project that
>> overlapped my import project and they changed the status on the
>> intersecting tiles to done.  This is keeping people from digitizing when
>> they could be importing higher quality data.
>>
>>
>>
>> Joe
>>
>>
>>
>>
>>
>>
>>
>> *From: *Andrew Matheny 
>> *Sent: *Friday, May 26, 2017 4:57 PM
>> *To: *OpenStreetMap talk-us list ;
>> impo...@openstreetmap.org
>> *Subject: *[Imports] Fort Worth, Texas import
>>
>>
>>
>> Hello all-
>>
>>
>>
>> With the Dallas building import completed except for 1 or 2 residential
>> blocks, I've begun planning a building import for Fort Worth, the next
>> largest city in the Dallas-Fort Worth area.
>>
>>
>>
>> The permissions, process, and test results have been documented on the
>> Wiki here: https://wiki.openstreetmap.org/wiki/Fort_Worth,_Texas_import .
>>
>>
>>
>> There have also been some recent initiatives by the community (see
>> http://tasks.openstreetmap.us/project/95 ) to trace buildings, and so
>> I'd like to accelerate this import project and have the community help
>> double check the imported data. This will help save the community's time
>> from having to start with a blank slate vs. being a pair of fresh eyes that
>> can make the data really, really good.
>>
>>
>>
>> As always, any feedback would be much appreciated.
>>
>>
>>
>> Best Regards,
>>
>>
>>
>> Andrew Matheny
>>
>> andrewdmath...@gmail.com
>>
>>
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Fort Worth, Texas import

[Jinal Foflia]

Hey Joe, Andrew,

With regard to this import moving ahead, we have decided to archive the
project in the tasking manager [0] to avoid community working on these
tasks and digitize data.

[0] - https://lists.openstreetmap.org/pipermail/talk-us/2017-May/017373.html


Cheers,
Jinal Foflia

On Sat, May 27, 2017 at 11:39 PM,  wrote:

> Andrew,
>
>
>
> Looks good to me and a great follow up to the Dallas project.  I would
> suggest contacting the project lead for project 95, they appear to work at
> mapbox.  I contacted the mapbox user that created a digitizing project that
> overlapped my import project and they changed the status on the
> intersecting tiles to done.  This is keeping people from digitizing when
> they could be importing higher quality data.
>
>
>
> Joe
>
>
>
>
>
>
>
> *From: *Andrew Matheny 
> *Sent: *Friday, May 26, 2017 4:57 PM
> *To: *OpenStreetMap talk-us list ;
> impo...@openstreetmap.org
> *Subject: *[Imports] Fort Worth, Texas import
>
>
>
> Hello all-
>
>
>
> With the Dallas building import completed except for 1 or 2 residential
> blocks, I've begun planning a building import for Fort Worth, the next
> largest city in the Dallas-Fort Worth area.
>
>
>
> The permissions, process, and test results have been documented on the
> Wiki here: https://wiki.openstreetmap.org/wiki/Fort_Worth,_Texas_import .
>
>
>
> There have also been some recent initiatives by the community (see
> http://tasks.openstreetmap.us/project/95 ) to trace buildings, and so I'd
> like to accelerate this import project and have the community help double
> check the imported data. This will help save the community's time from
> having to start with a blank slate vs. being a pair of fresh eyes that can
> make the data really, really good.
>
>
>
> As always, any feedback would be much appreciated.
>
>
>
> Best Regards,
>
>
>
> Andrew Matheny
>
> andrewdmath...@gmail.com
>
>
>
> ___
> 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] Fort Worth, Texas import

[joe.sapletal]

Andrew,

Looks good to me and a great follow up to the Dallas project.  I would suggest 
contacting the project lead for project 95, they appear to work at mapbox.  I 
contacted the mapbox user that created a digitizing project that overlapped my 
import project and they changed the status on the intersecting tiles to done.  
This is keeping people from digitizing when they could be importing higher 
quality data.

Joe



From: Andrew Matheny
Sent: Friday, May 26, 2017 4:57 PM
To: OpenStreetMap talk-us list; impo...@openstreetmap.org
Subject: [Imports] Fort Worth, Texas import

Hello all-

With the Dallas building import completed except for 1 or 2 residential blocks, 
I've begun planning a building import for Fort Worth, the next largest city in 
the Dallas-Fort Worth area.

The permissions, process, and test results have been documented on the Wiki 
here: https://wiki.openstreetmap.org/wiki/Fort_Worth,_Texas_import .

There have also been some recent initiatives by the community (see 
http://tasks.openstreetmap.us/project/95 ) to trace buildings, and so I'd like 
to accelerate this import project and have the community help double check the 
imported data. This will help save the community's time from having to start 
with a blank slate vs. being a pair of fresh eyes that can make the data 
really, really good.

As always, any feedback would be much appreciated.

Best Regards, 

Andrew Matheny 
andrewdmath...@gmail.com

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

Re: [Talk-us] [Imports] Dakota County, MN Building and Address Import

[OSM Volunteer stevea]

> What I need help with is:
>   • I can export the data out into the chunks in Shp format fairly 
> easily, I know how to script that.  And I have decent polygons for doing so.  
> I need a good tool for converting that to OSM, in bulk.

Hi Joe:  I think you are on the right track here, but I don't think you need to 
convert the shapefiles in bulk.  OSM's rather powerful editor JOSM has a plugin 
that can read (but not write) shapefiles directly.  So as long as your 
data-process pipeline converts to shapefile, just use JOSM to open these 
directly.  It is not required, but in your data import process, a good first 
step after opening in JOSM might be to write back to a file using File/Save, 
effectively "converting" from shapefile to .osm format with the simple process 
of "open, then save."  True, this is a manual process and to automate it ("in 
bulk" as you say) might prove a challenge, but the steps are here for you to 
use.

Your import page looks like a great start and so does your GitHub page.  
However, you mention there you get an error regarding WMS and I've had similar 
trouble with datasets that need a new coordinate system set up for them.  You 
might need to install GDAL (GDAL_Complete in your case) and use its ogr2ogr 
tool to convert to WGS84, OSM's native coordinate system.  If you research this 
and discover I'm correct, I can send you my "Ten Step" document that I used to 
do a similar import of US Forest Service (multi)polygons that include the 
process necessary to do the coordinate system translation.  Just ask!

Good luck with your import, (and yes, "herding cats," um, "finding helpful 
additional volunteers to help you" can be the hardest part),

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

Re: [Talk-us] [Imports] Dakota County, MN Building and Address Import

[Clifford Snow]

On Wed, Mar 15, 2017 at 10:48 AM,  wrote:

> What I need help with is:
>
>1. I can export the data out into the chunks in Shp format fairly
>easily, I know how to script that.  And I have decent polygons for doing
>so.  I need a good tool for converting that to OSM, in bulk.
>
> I use https://github.com/pnorman/ogr2osm - it converts shapefiles to OSM
xml format. The script allows a translation python script to convert
shapefile data to osm key value combinations.


>1. I need help defining/setting up in the US Tasking server.
>Who/what/where/etc?
>
> The US tasking manager is tasks.openstreetmap.org. Ian Dees can get you
added to created new tasks. Let me know if you need his email. I can assist
you if you need help configuring.


>1. Community support that this looks like a good idea.  (this should
>probably be number 1).
>
> It is now!




-- 
@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

Re: [Talk-us] [Imports-us] OSM-Colorado Mappy Hour Denver Buildings Import Discussion

[Mike Thompson]

The data here:
http://gis.drcog.org/datacatalog/content/planimetrics-2014-building-roofprints

Doesn't seem to match the description on the wiki.  Perhaps it has already
been converted partly to the OSM tagging (e.g. sheds and garages are
separate)?



On Tue, Jan 24, 2017 at 6:20 PM, Mike Thompson  wrote:

> Russ,
>
> This is very exciting to see this coming along.  Let me know how I can
> help. Hopefully we can use its success to convince other government bodies
> in Colorado to allow us to import their data into OSM!  Here are a few
> comments.
>
> re: "The Denver Regional Council of Governments (DRCOG), in partnership
> with local governments and public entities, has purchased detailed
> infrastructure data..." - This makes it sound like they purchased a
> commercial dataset, which raises questions about licensing in my mind.  I
> suspect that what happened is they "contracted for the collection of
> detailed infrastructure data..." In other words, it was work for hire, and
> they own all rights to the data,. Therefore, as long as the right official
> within DRCOG signs off, we are good (no third party vendor has any
> ownership rights in the data and doesn't have to be consulted). If this is
> in fact the case, someone may wish to change the wording.
>
> "Tagging Plans", "OTHER_TAG" - does this contain any useful information we
> can map to OSM tags?
>
> re: "Building Roofprints (poly) - Stereo-compiled (3D)"
> * Where applicable, are the buildings in the source data orthogonal
> (square corners) - like we try to create in OSM?
> * re "multi-level commercial/industrial buildings" I presume this means a
> building that has multiple roof heights, not multiple levels/floors inside
> the building. For example a building that has one section that is two
> stories high and has a roof height of 20 feet, and another section that is
> three stories high and has a roof height of 30 feet.
> * re "multi-level commercial/industrial buildings" - consider relations
> to group the various building parts together. [1]
>
> A "parking structure" should probably be tagged:
> amenity=parking
> parking=multi-storey  [3]
> (not sure it should get a building tag)
>
> A "tank" should probably not be tagged as building=, but rather just
> man_made=storage_tank [2]
>
> Not all "medical" buildings will be hospitals.
>
> Nothing is said about how the features other than buildings will be
> imported.
>
> Nothing is said about how the imported data will be conflated with the
> existing OSM data (I see there is a place holder).
>
> re "Merge Colorado Office of Information Technology (OIT) state address
> layer..." - does this data have a ODbL compatible license?
>
> Mike
>
> [1] https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
> [2] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstorage_tank
> [3] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking
>
>
> On Tue, Jan 24, 2017 at 4:21 PM, Russell Deffner 
> wrote:
>
>> Greetings all, this is a cross-post :)
>>
>>
>>
>> For some of you this may be old news/reminder.  Last spring the Denver
>> Regional Council of Governments approached our local group, OSM-Colorado
>> , to discuss if and how a ton of
>> planimetric data that they have collected and released as public domain
>> could also be added to OpenStreetMap.  Since then we’ve been discussing
>> with the local mappers and working together with DRCOG to prepare a pilot
>> import for their building dataset and we’re very close to that goal. This
>> email is mainly a ‘last call’ for the local/US community to review what we
>> have outlined on the wiki: http://wiki.openstreetmap.org/
>> wiki/Denver_Planimetrics_Import before we send notice to the main
>> imports list.
>>
>>
>>
>> The other thing this email is, and why I’m cross-posting, is because we’d
>> love to have you come discuss the import and other OSM stuff at a Mappy
>> Hour tomorrow the 25th; details: https://www.meetup.com/OSM-Col
>> orado/events/237116910/
>>
>>
>>
>> Of course if you can’t make mappy hour please email me any comments,
>> thoughts, suggestions or advice; thank you!
>>
>> =Russ
>>
>>
>>
>> Russell Deffner
>>
>> russdeff...@gmail.com
>>
>>
>>
>> ___
>> Imports-us mailing list
>> imports...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports-us
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports-us] OSM-Colorado Mappy Hour Denver Buildings Import Discussion

[Mike Thompson]

Russ,

This is very exciting to see this coming along.  Let me know how I can
help. Hopefully we can use its success to convince other government bodies
in Colorado to allow us to import their data into OSM!  Here are a few
comments.

re: "The Denver Regional Council of Governments (DRCOG), in partnership
with local governments and public entities, has purchased detailed
infrastructure data..." - This makes it sound like they purchased a
commercial dataset, which raises questions about licensing in my mind.  I
suspect that what happened is they "contracted for the collection of
detailed infrastructure data..." In other words, it was work for hire, and
they own all rights to the data,. Therefore, as long as the right official
within DRCOG signs off, we are good (no third party vendor has any
ownership rights in the data and doesn't have to be consulted). If this is
in fact the case, someone may wish to change the wording.

"Tagging Plans", "OTHER_TAG" - does this contain any useful information we
can map to OSM tags?

re: "Building Roofprints (poly) - Stereo-compiled (3D)"
* Where applicable, are the buildings in the source data orthogonal (square
corners) - like we try to create in OSM?
* re "multi-level commercial/industrial buildings" I presume this means a
building that has multiple roof heights, not multiple levels/floors inside
the building. For example a building that has one section that is two
stories high and has a roof height of 20 feet, and another section that is
three stories high and has a roof height of 30 feet.
* re "multi-level commercial/industrial buildings" - consider relations to
group the various building parts together. [1]

A "parking structure" should probably be tagged:
amenity=parking
parking=multi-storey  [3]
(not sure it should get a building tag)

A "tank" should probably not be tagged as building=, but rather just
man_made=storage_tank [2]

Not all "medical" buildings will be hospitals.

Nothing is said about how the features other than buildings will be
imported.

Nothing is said about how the imported data will be conflated with the
existing OSM data (I see there is a place holder).

re "Merge Colorado Office of Information Technology (OIT) state address
layer..." - does this data have a ODbL compatible license?

Mike

[1] https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
[2] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstorage_tank
[3] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking


On Tue, Jan 24, 2017 at 4:21 PM, Russell Deffner 
wrote:

> Greetings all, this is a cross-post :)
>
>
>
> For some of you this may be old news/reminder.  Last spring the Denver
> Regional Council of Governments approached our local group, OSM-Colorado
> , to discuss if and how a ton of
> planimetric data that they have collected and released as public domain
> could also be added to OpenStreetMap.  Since then we’ve been discussing
> with the local mappers and working together with DRCOG to prepare a pilot
> import for their building dataset and we’re very close to that goal. This
> email is mainly a ‘last call’ for the local/US community to review what we
> have outlined on the wiki: http://wiki.openstreetmap.org/
> wiki/Denver_Planimetrics_Import before we send notice to the main imports
> list.
>
>
>
> The other thing this email is, and why I’m cross-posting, is because we’d
> love to have you come discuss the import and other OSM stuff at a Mappy
> Hour tomorrow the 25th; details: https://www.meetup.com/OSM-
> Colorado/events/237116910/
>
>
>
> Of course if you can’t make mappy hour please email me any comments,
> thoughts, suggestions or advice; thank you!
>
> =Russ
>
>
>
> Russell Deffner
>
> russdeff...@gmail.com
>
>
>
> ___
> Imports-us mailing list
> imports...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Paul Johnson]

On Tue, Aug 2, 2016 at 10:59 AM, Clifford Snow 
wrote:

>
> On Tue, Aug 2, 2016 at 6:01 AM, Frederik Ramm  wrote:
>
>>sidewalk tagging in OSM is a complex issue. The fact that sidewalks
>> are not tagged as individual geometries is not purely a shortcoming,  it
>> is a compromise that keeps OSM data editable. Having individual
>> geometries for every single sidewalk on the planet will not only
>> massively increase the data volume but also require new and better tools
>> for editing, e.g. moving the geometry of a street without having to move
>> three parallel lines manually and so on.
>>
>
> Frederik, I thought you were for only add objects that can be surveyed on
> the ground? Isn't that what they are proposing?
>
> We tell people not to map for the renderer. In the same spirit shouldn't
> we tell people not to let the limitations of the editor stop them from
> mapping?
>

I tend to agree, particularly for pedestrian modes.  Sidewalks and
pedestrian crossings are pretty easy to verify even from the air and this
will be at least rational for most automated routing systems and a good
starting point (even if it means multiple ways per street, short of some
form of lanes type tagging, which I think gets messy for things like
sidewalks that have a curb (or more severe) barrier).   It does give the
most reasonable routing assumption (that is, you can't just freerun
midblock from sidewalk to sidewalk).  Most routing engines will figure it
out fairly quickly if you do this anyway, however (and any highly-tuned
routing engine should be able to make an educated guess by context anyway).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Greg Morgan]

On Sun, Aug 7, 2016 at 5:04 AM, Marc Gemis  wrote:
> On Sun, Aug 7, 2016 at 12:40 AM, Greg Morgan  wrote:
>> look at the recent turn lane work that MapBox is performing. They
>> have done a wonderful job of finding issues and developing use cases
>> for the rest of the community.  Far worse than the alleged GIGO of
>> this import is the NINO.  Without out MapBox's activity we would not
>> have a well developed definition of turn lanes.  Without sideway data
>> mapped and worked on, we'll get no where with these kinds-of
>> discussions.  I look forward to see what the Washington community will
>> find.  I am still working out details of my sidewalk edits.  I'd like
>> to build on the Washington data that will be developed.
>> https://github.com/mapbox/mapping/wiki/Mapping-guide-for-turn-lanes-from-imagery
>> https://github.com/mapbox/mapping/wiki/QA-for-turn-lane-data
>
> Huh ? The German community had turn:lane mapping as a week project
> (don't take  that too literally) back in November 2014. Thousands of
> turn lanes have been added in the months after the idea was launched
> in "DACH" (Germany, Switserland & Austria). I had been mapping
> hundreds of them in Belgium since spring 2014, all based on the JOSM
> style developed by Martin Vonwald.
> Please do not make it sound like Mapbox pushed turn:lane mapping
> forward. Maybe this is true for the US, but not for Western Europe.
> OsmAnd has turn lane navigation since the summer of 2015.

In 2014 turn:lane mapping was not on my radar.  I have not used
OsmAnd. I had/have no clue of your activity until now.  In the last
six years I have often turned to Western Europe for examples but
turn:lane mapping has not been one of them. What MapBox has pushed
forward is excellent documentation and published it in such a way that
the documentation was clear and drew my interest.  Moreover, what
really caught my eye is how the Portland community responded to a
mistake during the mapping process.  The Portland community did not
call in the DWC to break both of the mapper's knee caps with a
baseball bat.  The issue was repaired and the community moved forward.

Regards,
Greg

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

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Greg Morgan]

> Again this seems to be is the "I'm waiting for someone else to do something"
> line.  If you want a map rendering that shows stop signs, create one, like I

I am not standing in any line.  If I find an issue that I don't think
has been addressed or the original author did not understand is an
issue, then I file a bug report to the best my abilities.  That
doesn't mean I have to pick up the language and supply the patch.  The
way that open source works is that you don't always have to be the
coder.  Besides I would put up Butt ugly tiles that only a mother
would dare hang on her fridge and be proud of.  Then again, Tiles At
Home was Butt ugly and effective for mappers to see there changes.
https://github.com/openstreetview/josm-plugin/issues/2
https://github.com/openstreetview/uploader/issues/5

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

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[ajt1...@gmail.com]

On 06/08/2016 23:40, Greg Morgan wrote:


Again relevance:  I am still waiting for a stop sign to be rendered a
year after it was requested. If we wait until a stop sign gets all
artsie and fartsie, then it will never be rendered and it will never
be mapped or shall I say mappers will become uninterested without a
reward for their efforts.  We deny one stop light towns the pleasure
of seeing something happen on the map.  We need this kind of data
before the renders can even have some use cases to work from.
https://github.com/gravitystorm/openstreetmap-carto/issues/1683




Again this seems to be is the "I'm waiting for someone else to do 
something" line.  If you want a map rendering that shows stop signs, 
create one, like I did for sidewalks*.  Back in the day of hand-crafting 
Mapnik XML there was a seriously high bar to clear before "making your 
own map style", but now with CartoCSS (for which thanks, Mapbox!) that 
simply isn't the case any more.  If what you do makes sense at a local 
or national level it can get picked up at that level, and it'll stand 
much more chance of being included in one of the styles on the main 
osm.org site if you've got an example that says "here's how to do it and 
here's what it looks like"**.


Best Regards,

Andy


* https://www.openstreetmap.org/user/SomeoneElse/diary/38136

** 
https://github.com/gravitystorm/openstreetmap-carto/issues/1260#issuecomment-225009856



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

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Thomas Disley]

Thank you for your comments Greg! We've been drafting a longer response
that we wanted to share, and this seems like a good moment to jump in and
do so. Firstly, thank you to everyone for your engaging feedback! We’ve
learned a huge amount about the weaknesses and strengths of our proposal.

We think it would be helpful to talk about our motivations in posting this
import (and the schema suggestion), to give our points some context. We
have started this project with the goal of making sidewalks in OSM more
useful for the greater community, particularly people with limited
mobility. With its principles of openness and inclusion, OSM is uniquely
positioned to adopt a data model that can make a big difference for people
who use wheelchairs, crutches, or otherwise have difficulties walking,
while also improving the data in the map. While we hope this will have a
global impact, we are starting with a local import, are engaging the local
OSM community, and are setting up stakeholder relationships for the
maintenance of the data.

We would like to distinguish, as best we can, our schema proposal (on the
OSM wiki) from the import. The data to be imported does not have enough
metadata to make use of all the tags we are suggesting, and primarily comes
down to annotating the basic feature-level descriptions of sidewalks,
crossings, and curb ramps. We may be able to add one or two more pieces of
information (like width, surface, and kerb tags), but we consider this to
be an opportunity more than a requirement. In all cases, the tags we would
use are not new or in violation of OSM standards, in our understanding -
they are all in heavy use in many locations, with wiki entries, even though
tagging streets with sidewalk information is popular in other locales.

To address some of the concerns about community engagement and our import
proposal in general, we’d like to detail what we have done so far to make
it clear that we’re engaging with the local community and attempting to go
through all the right steps.


   1.

   We started (after much research) by posting the schema towards the end
   of June to get feedback
   2.

   We presented our schema at the SOTMUS to get direct feedback, especially
   to learn how it could adapt to places outside of Seattle. We also presented
   our plan to actually to do an import of Seattle data to test this
   schema, and have received positive feedback from the local OSM community so
   far. This put us in contact with a large number of OSM community members
   from the U.S. and international communities, and we received overwhelmingly
   positive feedback.
   3.

   We also connected with the LA building import team (at the SOTMUS) and
   have modeled our import proposal after theirs.
   4.

   After posting the proposal, we’re engaging the tagging and import
   mailing lists to get more feedback in case there are unforeseen problems.
   5.

   Next we plan on running a test import from start to finish, converting
   Seattle municipal data to (a subset of) the proposed schema, with an output
   of OSM XML. We’ll then test integrating with a locally hosted copy of
   OpenStreetMap through a human verification process (the tasking manager +
   JOSM plugins), to meet with OSM best practices.
   6.

   Only once we’ve learned from this process, and ensured that our schema
   meets community expectations were we planning to actually import the
   Seattle data set. The goal here would be to take a first step to be able to
   show the benefits of having this standardized sidewalks schema, especially
   for the limited mobility community.
   7.

   For maintainability (and immediate impact), we have several stakeholder
   relationships interested in this project. These include the NGO Feet
   First, the Puget Sound Regional Council (they are discussing an official
   capacity), the King County Mobility Coalition, groups within King County
   Metro, and of course the local OSM community, with whom we’re hosting a
   Mapathon on August 7, 2016.


What are everyone’s thoughts? Are there any additional steps you would
recommend?

Regarding the import challenges:

In terms of putting the burden on existing volunteers, we actually think
that this could be used as a strategy to get more people into mapping. We
were lucky enough to speak to a lot of OSM meetup organizers at SOTMUS and
something which came back consistently is: they need interesting projects
to get people to turn out for mapathon events, and projects with a social
angle are really effective at this. Obviously this isn’t a new idea, and we
can point to the work done by the HOT team as a really positive example of
this. Additionally, we have found that a more human-centric approach draws
people in. We are interested, afterall, in improving walking conditions for
everyone.

We are also developing mapping tools (iD modes, mobile applications, and
potentially a JOSM plugin) to make mapping sidewalks, crossings, and curb
ramps easier. We 

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Greg Morgan]

On Tue, Aug 2, 2016 at 6:01 AM, Frederik Ramm  wrote:
> Meg,
>
>sidewalk tagging in OSM is a complex issue. The fact that sidewalks
> are not tagged as individual geometries is not purely a shortcoming,  it
> is a compromise that keeps OSM data editable. Having individual
> geometries for every single sidewalk on the planet will not only
> massively increase the data volume but also require new and better tools
> for editing, e.g. moving the geometry of a street without having to move
> three parallel lines manually and so on.
>
> There have been several local imports of sidewalk data that were removed
> again because lack of prior discussion and/or because they were
> single-purpose imports that did not care about integration with the rest

I don't see how that is relevant here since Meg is engaging in a conversation.

> of OSM (for example: what should rendering engines do with sidewalks;

Again relevance:  I am still waiting for a stop sign to be rendered a
year after it was requested. If we wait until a stop sign gets all
artsie and fartsie, then it will never be rendered and it will never
be mapped or shall I say mappers will become uninterested without a
reward for their efforts.  We deny one stop light towns the pleasure
of seeing something happen on the map.  We need this kind of data
before the renders can even have some use cases to work from.
https://github.com/gravitystorm/openstreetmap-carto/issues/1683


> how do they integrate with normal footways; how is a sidewalk linked to
> the road along which it runs so that routing engines can say "follow
> sidewalk along XY road" instead of "follow unnamed footway"; how can
> routing and rendering use individual sidewalks and still gracefully fall
> back to another method where these are not defined, and so on).
>
> People are experimenting with different ways of mapping sidewalks.
> Under no circumstances should you perform an import that creates facts
> before your proposal for separate mapping of sidewalks has been
> discussed more widely.

I look at the recent turn lane work that MapBox is performing. They
have done a wonderful job of finding issues and developing use cases
for the rest of the community.  Far worse than the alleged GIGO of
this import is the NINO.  Without out MapBox's activity we would not
have a well developed definition of turn lanes.  Without sideway data
mapped and worked on, we'll get no where with these kinds-of
discussions.  I look forward to see what the Washington community will
find.  I am still working out details of my sidewalk edits.  I'd like
to build on the Washington data that will be developed.
https://github.com/mapbox/mapping/wiki/Mapping-guide-for-turn-lanes-from-imagery
https://github.com/mapbox/mapping/wiki/QA-for-turn-lane-data

Thank you Meg.

Regards,
Greg

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

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Frederik Ramm]

Clifford,

On 08/02/2016 05:59 PM, Clifford Snow wrote:
> We tell people not to map for the renderer. In the same spirit shouldn't
> we tell people not to let the limitations of the editor stop them from
> mapping?

Usually, when you deal with individual mappers who come up with a
tagging scheme, you can simply let them try it because they are just one
person and the amount of stuff they can survey in any given time is
limited. Before they can break a lot, others will notice what's going
on, and a discussion can develop.

Importing sidewalks for a large city is something different. It allows
you to add thousands of objects in a short time frame. Hence the request
to "talk before you import" - something we don't expect from the hobby
mapper who adds a few sidewalks according to a tagging schema he has
made up.

> I'm not following you. They did announce their plans and are discussing
> the proposal with the community, including how to route. 

I am concerned that they might want to start importing data 5 days from
now which is certainly not enough time for a solid discussion. Maybe I
misread.

> Unlike existing routing systems, they are proposing to enable people
> with limited mobility to find a route to their location.  

As I have said, there have been a number of publicly funded projects
that had this laudable aim. Solving the issue by adding ways for every
sidewalk is one of many potential solutions; a solution that has
advantages and drawbacks which should be discussed widely before an
import is done to "kick-start" world-wide adaption of a tagging schema.

> Yet their plan is the easiest for a new mapper to follow. I've followed
> mapping of sidewalks. Where are these proposals you talk about? 

I linked some in my post to the tagging list. Some of the
failed/single-minded projects in the past didn't even bother documenting
their tags on the wiki, insofar this project is superior - and it's
totally ok for them to start a discussion. Just not an import one week
after mentioning that by-the-way-we-have-a-proposal-here ;)

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

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Clifford Snow]

On Tue, Aug 2, 2016 at 6:01 AM, Frederik Ramm  wrote:

>sidewalk tagging in OSM is a complex issue. The fact that sidewalks
> are not tagged as individual geometries is not purely a shortcoming,  it
> is a compromise that keeps OSM data editable. Having individual
> geometries for every single sidewalk on the planet will not only
> massively increase the data volume but also require new and better tools
> for editing, e.g. moving the geometry of a street without having to move
> three parallel lines manually and so on.
>

Frederik, I thought you were for only add objects that can be surveyed on
the ground? Isn't that what they are proposing?

We tell people not to map for the renderer. In the same spirit shouldn't we
tell people not to let the limitations of the editor stop them from mapping?


> There have been several local imports of sidewalk data that were removed
> again because lack of prior discussion and/or because they were
> single-purpose imports that did not care about integration with the rest
> of OSM (for example: what should rendering engines do with sidewalks;
> how do they integrate with normal footways; how is a sidewalk linked to
> the road along which it runs so that routing engines can say "follow
> sidewalk along XY road" instead of "follow unnamed footway"; how can
> routing and rendering use individual sidewalks and still gracefully fall
> back to another method where these are not defined, and so on).
>

I'm not following you. They did announce their plans and are discussing the
proposal with the community, including how to route.
Unlike existing routing systems, they are proposing to enable people with
limited mobility to find a route to their location.

>
> Several ideas have been proposed to get around mapping sidewalks as
> individual geometries, which is in many ways the most primitive way to
> tackle the problem and the one that puts the most work on the shoulders
> of our volunteers.
>

Yet their plan is the easiest for a new mapper to follow. I've followed
mapping of sidewalks. Where are these proposals you talk about?

Your wiki page states that you had "feedback from the global OSM
> community"; I'm surprised that these details seem to have escaped you
> until now. Which sidewalk mapping experiments in OSM have you studied,
> and what have you learned? Which global OSM community did you talk to
> and where?
>

Frederik - may I suggest you comment on their proposal in a more
constructive method. I was septical of their approach when I first learned
of their plans, yet as I learn more, I've come to accept that they have a
well thought out proposal. Certainly the community should help make sure
that their proposal doesn't have some unforeseen issue. As a walker, the
current OSM sidewalk tagging scheme is lacking and just a pain when with
complex intersections. And yes I have added the entire sidewalk, manually,
to my town.

Best,
Clifford

-- 
@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

Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org

[Paul Johnson]

On Fri, Jul 29, 2016 at 3:02 PM, Frederik Ramm  wrote:

> Hi,
>
> On 07/29/2016 03:42 AM, Clifford Snow wrote:
> > Thanks for pointing out my lapse. You are correct. I've used parcel
> > boundaries for parks a number of time.
>
> Nonetheless (in order not to confuse the original poster) let's
> reiterate that property lines themselves do not belong in OSM; only
> where they can be used to deduce the bounds of something we *do* want in
> OSM will they find their way into the database. We will not map
> individual property lines in e.g. a residential neighbourhood (much less
> import them).


This feels like a usage case, somewhat specific to a far more gruanular
scenario, in part of OSM's self making.

At least in the US, even in residential areas, there's a high degree of
difference between landuse=highway and landuse=residential.  I get that
land use changes over time, but, are we trying to produce a static map, or
a flexible map?  I'm generally on the assumption of the latter (though my
examples of Oklahoma as a whole and Oregon's Metro Region plus Clark
County, Washington as critters with their own quirks) seems to be fairly
unique.  Particularly with three-dimensional tagging in place, is there a
reason to NOT handle property-lines on the ground?

I mean, Tulsa Oklahoma's only something like the ~924234324 largest city in
the world, by way of a number I totally pulled from deep under my tail (in
reality, it's one of the largest metropolitan or micropolitan statistical
areas in the US; top 100 even, out of 929 metro or micropolitan areas in
the US, as defined by the census, for which Tulsa metro is 57th largest in
America), but even having a statistical baseline literally good enough for
government work, and usually (always?) surveyable based on identifying
markings at the extreme corners...
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org

[Paul Johnson]

On Thu, Jul 28, 2016 at 5:12 PM, Clifford Snow 
wrote:

>
> On Thu, Jul 28, 2016 at 12:02 PM, teslas_moustache <
> teslas_mousta...@riseup.net> wrote:
>
>>
>> I'm not sure if property lines and ownership are useful. And I don't
>> think that building outlines are included, so I may need to continue
>> with drawing rectangles for a while. But hey, addresses!
>>
>> What needs to be done?
>>
>
> While property lines don't belong in OSM,
>

I barely understand this perspective at face value.  I get that these are
in flux, but they're commonly verifiable close enough to reflect
on-the-ground use, or the county wouldn't collect that as a data point to
start with.


> they can be useful. Having parcel boundaries can be useful to figure out
> the address of a building. Especially if you can get access to the
> property, i.e. the owner has no trespassing signs posted. Other tools such
> as QGIS and PostGIS come in handy for getting your data ready for import.
>

Basically this.  Both objectively for the vast majority of e911 plots and
subjectively for either multiple buildings for a single plot or multiple
addresses for a single building.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org

[Frederik Ramm]

Hi,

On 07/29/2016 11:46 PM, Jonathan Schleuss wrote:
> I'm kind of curious about this. Why not import those property lines? I'm
> not arguing for them, because it seems like a lot of work. But I note
> that in cities such as Fresno, they are in the map
>  as
> landuse=residential.

Yes, sadly some imports have been done in the past without consultation
and it will take some time to get rid of them.

>  What if we add all the buildings, all the trees,
> every bench? Why not add property boundaries? I'm thinking 2030 here.

If there's a fence on the boundary, you can map the fence. Or any other
physical marker, if you so desire. Mapping in-visible boundaries is a
bad idea because it runs against our desire to have things verifiable on
the ground - this is one reason that keeps us safe from a whole class of
edit wars where people disagree about something that cannot be proven.

We make an exception from that rule for admin boundaries because their
usefulness is so high that it overrules the problem (usually) not being
visible on the ground.

OpenStreetMap is, mostly, a project driven by people who contribute data
that they survey. Data imports can occasionally help but they're not the
mainstay of OSM.

A data set of parcel boundaries can easily be displayed on top of OSM,
or integrated into your rendering stack if you need these boundaries,
but it doesn't make much sense in OSM because it will usually not be
curated by individual mappers. It would just sit there, being replaced
by a new import once a year (or not) - OSM would be abused as a data
transport for third party data.

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

Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org

[Jonathan Schleuss]

Hi,

I'm kind of curious about this. Why not import those property lines? I'm not 
arguing for them, because it seems like a lot of work. But I note that in 
cities such as Fresno, they are in the map as landuse=residential. What if we 
add all the buildings, all the trees, every bench? Why not add property 
boundaries? I'm thinking 2030 here.

cheers,
Jon

On Jul 29, 2016, at 03:04 PM, Frederik Ramm  wrote:

Hi,

On 07/29/2016 03:42 AM, Clifford Snow wrote:
Thanks for pointing out my lapse. You are correct. I've used parcel
boundaries for parks a number of time.

Nonetheless (in order not to confuse the original poster) let's
reiterate that property lines themselves do not belong in OSM; only
where they can be used to deduce the bounds of something we *do* want in
OSM will they find their way into the database. We will not map
individual property lines in e.g. a residential neighbourhood (much less
import them).

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

Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org

[Frederik Ramm]

Hi,

On 07/29/2016 03:42 AM, Clifford Snow wrote:
> Thanks for pointing out my lapse. You are correct. I've used parcel
> boundaries for parks a number of time. 

Nonetheless (in order not to confuse the original poster) let's
reiterate that property lines themselves do not belong in OSM; only
where they can be used to deduce the bounds of something we *do* want in
OSM will they find their way into the database. We will not map
individual property lines in e.g. a residential neighbourhood (much less
import them).

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

Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org

[Greg Troxel]

Clifford Snow  writes:

> On Thu, Jul 28, 2016 at 12:02 PM, teslas_moustache <
> teslas_mousta...@riseup.net> wrote:
>
>> I'm not sure if property lines and ownership are useful. And I don't
>> think that building outlines are included, so I may need to continue
>> with drawing rectangles for a while. But hey, addresses!
>
> While property lines don't belong in OSM, they can be useful. Having parcel
> boundaries can be useful to figure out the address of a building.
> Especially if you can get access to the property, i.e. the owner has no
> trespassing signs posted. Other tools such as QGIS and PostGIS come in
> handy for getting your data ready for import.

Two non-import thoughts:

  In Mass we have a tiled raster datalayer rendered from the vector
  parcels database.  This is transparent with white lines for lot lines
  and address/parcel.  It's highly useful for figuring out addresses and
  also adjusting geometry of open space, parks, etc. when making landuse
  polygons.  Code (by Jason Remillard, not me) is at:
  https://github.com/jremillard/osm_massgis_tiles

  Even though the current mostly consensus is that property lines don't
  belong in OSM, they are really useful in making maps.  So if you can
  produce and host an osm-format file with property lines (I use
  boundary=parcel as the tag in my private files), then people can merge
  them with the OSM data to produce e.g. a garmin-format map or a map
  for OSMand, or their own mapnik render.   Perhaps OSMF-US has
  resources to host these files.


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

Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org

[Clifford Snow]

On Thu, Jul 28, 2016 at 4:51 PM, Kevin Kenny 
wrote:

> Property lines also define the bounds of public areas like parks,
> schoolyards, cemeteries, and airfields, which surely do belong in OSM. They
> aren't infallible, but they are often more precise than guessing from
> orthophotos. This has to be considered intermediate to advanced mapping,
> since these features typically result from combining multiple lots, which
> are often still separate in the tax rolls. Moreover, use of the property by
> multiple agencies may have multiple land uses for a single tax parcel.
> Still, it's a pretty good starting point. Even the fact that the tax rolls
> identify a parcel as belonging to a government agency is an indication that
> there is likely to be a mappable feature there.


Kevin,
Thanks for pointing out my lapse. You are correct. I've used parcel
boundaries for parks a number of time.

Clifford


-- 
@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

Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org

[Kevin Kenny]

On Jul 28, 2016 6:14 PM, "Clifford Snow"  wrote:
> While property lines don't belong in OSM, they can be useful. Having
parcel boundaries can be useful to figure out the address of a building.
Especially if you can get access to the property, i.e. the owner has no
trespassing signs posted. Other tools such as QGIS and PostGIS come in
handy for getting your data ready for import.

Property lines also define the bounds of public areas like parks,
schoolyards, cemeteries, and airfields, which surely do belong in OSM. They
aren't infallible, but they are often more precise than guessing from
orthophotos. This has to be considered intermediate to advanced mapping,
since these features typically result from combining multiple lots, which
are often still separate in the tax rolls. Moreover, use of the property by
multiple agencies may have multiple land uses for a single tax parcel.
Still, it's a pretty good starting point. Even the fact that the tax rolls
identify a parcel as belonging to a government agency is an indication that
there is likely to be a mappable feature there.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Updates:LA County building import (Los Angeles, California, USA)

[maning sambale]

Christoph,

Thank you for the observation.

Specific to "roads now intersect buildings indicating that mapping is
inaccurate - like here:"
They are mostly unreviewed TIGER import, I also saw one instance where
we have building but no roads.
This was already discussed by the import team and will be fixed during
the cleanup/validation stage.

Keep your  comments and suggestions coming! Will ticket each one and
fix whatever we can.
Thanks!


On Tue, Jul 19, 2016 at 8:14 PM, Christoph Hormann  wrote:
> On Tuesday 19 July 2016, maning sambale wrote:
>>
>> Another round of updates on LABuildings import.
>> Last week we've imported ~1.1M buildings in LA City. Over 100
>> usernames participated.
>> We are close to finishing Phase 1 (LA City) and will continue data QA
>> and cleanup if needed.
>
> A few observations from looking over the map there:
>
> * There are quite a few cases where gaps between buildings are either
> very small (significantly less than a meter) or buildings touch at a
> single node.  Both are usually artefacts (probably primarily due to
> roof based rather than footprint based outlines).
> * There seem to be a lot of cases where garages and sheds are tagged as
> building=house or building=residential - like here:
>
> https://www.openstreetmap.org/way/409191451
>
> * In some cases boundaries of pre-existing landuse polygons (like
> landuse=residential/landuse=industrial) and roads now intersect
> buildings indicating that mapping is inaccurate - like here:
>
> http://www.openstreetmap.org/#map=17/34.07461/-118.48376
>
> All of these problems could probably be turned into maproulette tasks or
> be otherwise worked into QA tools - although at least the first two
> will require on-the-ground assessment for proper correction.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--

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

Re: [Talk-us] [Imports] Status and progress: NYS DEC Lands reimport

[Kevin Kenny]

On Tue, Jul 19, 2016 at 8:25 AM, Greg Troxel  wrote:
> Martin Koppenhoefer  writes:
>> On this particular issue I believe you should use different tagging.
>> Currently there is almost no use of access=permit
>> http://taginfo.openstreetmap.org/tags/access=permit
>> Typically if you require a permission for access it is "private" (maybe
>> something with "access:conditional" would also be appropriate:
>> http://taginfo.openstreetmap.org/keys/access%3Aconditional#values ), you
>> could still link the detailed specifiication with a similar tag, like
>> access:website=http://www.dec.ny.gov/outdoor/7815.html
>> (choosing from the most frequently used tags, maybe it could be
>> "source:access"?)
>
> It seems like the tagging schema should be improved.  As I see it
> there's a big difference between
>
>   private, and really there is no expectation that some random person
>   can easily/reasonably get permission or that it's reasonable to ask
>
>   a permit system, where it's controlled somehow, but really you can go
>   there after you follow the rules, and there's an expectation that
>   permits will be issued to those who ask
>
> The second case also sort of applies to backcountry in national parks,
> except technically you only need a permit for camping overnight.
>
>
> Perhaps you are saying that access=conditional has some established
> semantics that would capture this.

That was exactly my thought. The distinction is real, it's observable
in the field, and it's common in places that I visit.

New York has its permit system in place
mostly so that the infrastructure will be there if they have to impose
access quotas someday. For the Long Island pine barrens and the New
York City watershed lands, the permit can be obtained immediately,
free of charge, by entering your contact information on a web site and
then printing the access card and parking tag. The access cards are
good for several years, so you don't even need to do this for every
trip.

For the High Peaks Wilderness, it's even easier. They have permit tags
on carbon paper forms at the trailheads. You fill out the form, take
one copy with you and leave the other copy in the box. I left that
one 'access=yes', since a traveller doesn't need to plan in advance
for it. Moreover, I didn't have a good map of the zones of the High
Peaks Wilderness, and the permit system applies only in the eastern
zone. The boundary is indefinite, following the relatively
inaccessible ridge over Nye, Street, and MacNaughton Mountains.
In the unlikely event that I were to climb one of those from the west
(a much harder route), I'd probably grab a permit card at Heart Lake
or Keene Valley the day before.

It would not surprise me at all to learn that this 'self-issued'
permit system is a peculiarly American thing. It seems to be just the
sort of messy and free-wheeling system that Americans are fond of, but
doesn't quite fit OSM's model of the world. (OSM hass come around
quite nicely, but I can certainly recall a time when the European
cultural assumptions were fairly pervasive.)

I had investigated access:conditional, but the schema doesn't seem
appropriate. It appears to have a formal syntax that is devoted to
specifying restrictions for the use of a motor vehicle router. I see
that I could write
access=private access:conditional="yes @ permit_holder"
but that's even rarer than 'access=permit' - taginfo shows only nine
uses of 'permit_holder' within 'access:conditional' in the whole of
OSM,

I'm already rendering a map using 'access=permit'. I can easily change
the rendering to whatever tagging scheme is decided on. Nevertheless,
it's important to my application, so there has to be some sort of
distinction between 'private: keep out' and 'make sure you have your
access card in your backpack'. Incidentally, this argument is one that
I hate to use, because the last couple of times I mentioned that I
can't tag two things exactly alike and expect to render them
differently, I was accuesd of 'tagging for the renderer.' I think that
argument rather misses the point: things tagged alike cannot be
rendered differently, whatever renderer is in use.

I do wish that the discussion had happened before I imported the New
York City DEP watershed lands. At the time, I asked, on 'talk-us' and
'imports', how to deal with the situation, and someone suggested that
the little-used 'access=permit' might be appropriate. As it stands, I
now likely have another project to deal with revising that tagging, at
such time as we arrive at a consensus what the tagging should be.

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

Re: [Talk-us] [Imports] Status and progress: NYS DEC Lands reimport

[Greg Troxel]

Martin Koppenhoefer  writes:

> On this particular issue I believe you should use different tagging.
> Currently there is almost no use of access=permit
> http://taginfo.openstreetmap.org/tags/access=permit
> Typically if you require a permission for access it is "private" (maybe
> something with "access:conditional" would also be appropriate:
> http://taginfo.openstreetmap.org/keys/access%3Aconditional#values ), you
> could still link the detailed specifiication with a similar tag, like
> access:website=http://www.dec.ny.gov/outdoor/7815.html
> (choosing from the most frequently used tags, maybe it could be
> "source:access"?)

It seems like the tagging schema should be improved.  As I see it
there's a big difference between

  private, and really there is no expectation that some random person
  can easily/reasonably get permission or that it's reasonable to ask

  a permit system, where it's controlled somehow, but really you can go
  there after you follow the rules, and there's an expectation that
  permits will be issued to those who ask

The second case also sort of applies to backcountry in national parks,
except technically you only need a permit for camping overnight.


Perhaps you are saying that access=conditional has some established
semantics that would capture this.


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

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

[Kevin Kenny]

On 05/19/2016 05:27 AM, Paul Norman wrote:
I was debugging some MP issues and came across the NYSDEClands 
import[1], done in 2010, consisting of natural areas. They have a 
number of unwanted tags[2], and a couple of other problems with their 
tags


Because there's a relatively small number of them, I think a 
mechanical edit is the best cleanup option. I'm proposing the following


- Removing NYDEC_Land:* tags
- Removing area=yes where there are other area tags
- Changing url=* to website=* where website does not already exist
- Leaving source=* intact
- Removing name=Unclassified

[1]: https://www.openstreetmap.org/user/NYSDEClands
[2]: e.g. https://www.openstreetmap.org/way/32002190

___
Imports mailing list
impo...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports


You are talking about an import that is near and dear to me: this is my 
home turf!


This import needs more significant rework than what you propose, and in 
fact, I wrote to Russ privately just the other day about it.


There's no update plan, although the source shapefile is updated regularly.

Multipolygons were rather a botch in the original import (for instance, 
most of Saranac Lake Wild Forest is missing (something I just recently 
noticed). The same thing had happened to Indian Lake Wilderness and 
Overlook Mountain Wild Forest.  Some of the multipolygons have 
topological problems.


Nodes are duplicated all over the place. Whenever I touch one of these 
areas (usually to disconnnect a way) it triggers a cascade of JOSM 
warnings.


Wildlife management areas are tagged merely with 'landuse=conservation', 
which is deprecated and does not render. They should be something more 
like 'leisure=nature_reserve boundary=protected_area protect_class=4', 
like the Pennsylvania State Game Lands. I would entertain an argument 
for a different protection class, maybe 14?


Wildlife management areas and multiple use areas have 'Wma' and 'Mua' in 
their names, which needs to be spelt out or at least capitalized.


The only real reason that I hadn't done it yet is that I'm trying to 
work up an update plan. I'm a good enough hand with PostGIS that I have 
a pretty good idea how to come up with the list of differences when a 
new version of the shapefile appears. But I'm ignorant of the tools for 
mechanical edits, and so it's been slow going. I'm quite meticulous 
about these things.


If you're willing, I think your time might be better spent on teaching 
me how to do the import.


That would have the pleasant side effect that I'd be able to do 
http://www.nyc.gov/html/dep/pdf/recreation/open_rec_areas.pdf by myself. 
I'm going to ask for the shapefile when I ask NYCDEP for permission. 
This is done out of a superabundance of caution, since permission should 
not be needed in any case. New York City's open data policy covers this 
data set, and we've done a good many other imports relying on the 
policy. If need be, I have scripts that have successfully web-scraped 
the individual maps for all of the areas except for Devasego Park in 
Greene County, the Ashokan day use area in Ulster County, and the Cross 
River and Kensico dams in Westchester County. The PDF maps for those 
four areas are images only - there's no vector polygon in them to be 
scraped. They're tiny compared with the others - more like city parks, 
while the others are huge tracts of mountain, forest and marsh.


Learning how to do this sort of job would also let me make faster 
progress toward getting the Adirondack waterways sorted. That's a much 
harder database job - it's a multiway conflation among what's already in 
there (a quasi-mechanical import of ponds, plus satellite image tracing 
of a handful of major rivers), NHD, the Adirondack wetland database, the 
USFWS wetland database, and the NYSDOT water shapefiles. Every single 
one of these has major errors and omissions, but conflating the 
redundant coverage actually promises to yield something fairly clean.


Generally speaking, survey quality in these areas is extremely poor. I'd 
say that the first topographic maps of the Adirondacks that were made to 
even the standards of the Victorian era were the ones produced in the 
1980s for the Winter Olympics in Lake Placid. And most online 
topographic map services don't even include them, because they were in 
metric units, used UTM rather than the state plane coordinate system, 
were referenced to NAD83 rather than NAD27, and were at 1:25000 rather 
than 1:24000 scale. They also were printed on rather poor paper, and 
shipped folded rather than rolled in mailing tubes. Because of that, no 
libraries have copies that really lie flat for scanning. They were huge 
sheets, since they were 7.5x15 minute double quads rather than 7.5x7.5. 
For that reason, a lot of their information simply never got digitized 
(or digitized well). A lot of the National Map stuff, NHD, and so on are 
actually based on the 1953 

Re: [Talk-us] [Imports] Proposed import cleanup: Olympic peninsula streams

[Christoph Hormann]

On Thursday 19 May 2016, Paul Norman wrote:
> - Simplifies them with JOSM, set to 2.5m threshold

That's not a good idea - incidently that is *never* a good idea for a 
meachanical edit, especially not with an absolute threshold.

I also don't see significant meaningless detail in the data so even if 
this was an original import i would not think this to be a wise 
measure.

Even if you decide to do this none the less you would have to make sure 
not to touch nodes that have been manually moved after the original 
import.

> - Changes source=US-NPS_import_... to source=US NPS

This should be completely removed from the nodes and only retained on 
ways.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-us] [Imports] RFC: LA County building import (Los Angeles, California, USA)

[maning sambale]

Hi,

We've started the import this during MaptimeLA [0] last April 2.
First project focused on Southside LA [1].
For any issues regarding the process and the data please post a ticket
in GH [2].

[0] http://www.meetup.com/MaptimeLA/events/229861154/
[1] http://labuildingsimport.com/project/2
[2] https://github.com/osmlab/labuildings/issues


On Sun, Mar 27, 2016 at 12:20 AM, Christoph Hormann
 wrote:
> On Thursday 24 March 2016, maning sambale wrote:
>>
>> > - Tagging still looks vague.  What you have on
>> > https://github.com/osmlab/labuildings/blob/master/README.md is just
>> > a list of OSM keys to use but there is no information on the values
>> > -
>>
>> Right, I updated the wiki to describe the tags.  Still a work in
>> progress, but see here:
>> https://wiki.openstreetmap.org/wiki/Los_angeles,_California/Buildings
>>_Import#Data_Preparation
>
> Thanks, this clarifies things a lot and mostly looks good.
>
> Regarding tagging plans please consider that building=farm is
> exclusively for residential building on a farm, not for other buildings
> with farming related use.
>
>> The initial offset we saw was due to re-projection issues from NAD83
>> to WGS84 datum.  By using a custom projection parameters the
>> difference is very minimal difference (10 micrometer precision
>> range). Reprojection is now step is now added in the wiki.
>
> OK. I was also concerned about vertical datum (i.e. reference geoid) for
> elevation values and feet vs. meters for ele and height.
>
> --
> Christoph Hormann
> http://www.imagico.de/



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--

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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Roman Yepishev]

Hi,

As Massachusetts slowly migrates back into winter, here is the status
update on the address import for Boston, MA.

License: As it turns out, all public City of Boston data is licensed CC
BY 4.0, which requires attribution. I have sent additional
clarification questions on whether the 'Contributors' page link/import
changeset source tag is sufficient to City of Boston officials as per
the wiki instructions.

Neighborhoods: I have completely split: Back Bay, Bay Village, Beacon
Hill, Chinatown, Dorchester, Financial District, Government Center,
Hyde Park, Jamaica Plain, South Boston, South End, West End, and
Roxbury. As of yesterday's merge, we have 75687 uniquely identified
buildings (up from 64K 3 weeks ago) and 1449 more are still waiting to
be split (2%). SAM contains address information on 89065 distinct
objects with addresses (some of them are buildings, some of them are
parks or references to buildings that were demolished a long ago), and
we have 85% overlap of OSM buildings and SAM objects.

Yay!

-- 
https://wiki.openstreetmap.org/wiki/Import/Boston_Street_Address_Manage
ment_%28SAM%29_Import

signature.asc
Description: This is a digitally signed message part
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Roman Yepishev]

Hi all,

Just an update on the current status.

1. I am waiting for a response from Boston GIS regarding the license
terms (MassGIS != Boston GIS, as I recently realized).
2. At this point the code will only be minimally tweaked as I have
implemented everything I originally planned:
 - Standalone buildings w/o numbers are tagged
 - Standalone buildings w/ numbers differing from SAM data are flagged
for further manual updates
 - Terraced buildings are marked with gpx waypoints/.osn note entries
for manual splitting/surveying.
 - source:addr=survey buildings are skipped.
 - Buildings containing an entrance that has an addr:housenumber are
skipped (most likely a manual survey).
 - Address nodes are added if there are multiple addresses for a
building within one tax parcel. Address nodes are in a separate .osc
file; if import is approved, these will be the last thing to be
imported.
3. I am going through the neighborhoods splitting the buildings. If
anybody is aware of an algorithm that can make this process easier
(buildings may span multiple parcels, and sometimes spill over parcels
they have no business being into) I'll be glad to hear about it.

I talked to Lars Ahlzen @ OSM Meetup this week and confirmed that
adding addr:city and addr:postcode to a building/address node is a good
thing.

-- 
https://wiki.openstreetmap.org/wiki/Import/Boston_Street_Address_Manage
ment_%28SAM%29_Import

signature.asc
Description: This is a digitally signed message part
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Roman Yepishev]

Hi Jason, all.

I added the addr:city to the tags to use w/o confirming first - what is
the balance between adding the address information directly on the
building as opposed to using the boundaries?

I suppose that for the ease of processing the building will need to
have as much information as possible, but then we will have two sources
of truth e.g. for city or zipcode - boundaries and the node.

Now, current status:

I have just terraced Back Bay (a historical district in Boston, old
narrow houses, around 1000 of them) and found this to be less fun than
I imagined :)

Additionally a look at South Boston shows that there are less building
ranges, and more building numbers that point to the same building (e.g.
number 45 is on first floor, 47 is on the second).

As much as I'd hate to do that, there appears to be no other way to
handle this than adding the address node, as I saw done in NY and
Seattle (and how e.g. Here maps handles it - no buildings, just numbers
on the ground). Now, that also means that I need to start operating on
the tax parcel shapefile to verify whether the building needs to be
split or an address node needs to be added.

I added an exception for buildings with source:addr=survey, as I found
that it is of no use trying to repeatedly mark a building which was
manually tagged and verified to have a different number than the
official one  as "fixme". So far there are ~3 buildings with this tag,
but there will be more as I am going through the dataset and buildings
on the ground.

-- 
https://wiki.openstreetmap.org/wiki/Import/Boston_Street_Address_Manage
ment_%28SAM%29_Import

signature.asc
Description: This is a digitally signed message part
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Greg Troxel]

Jason Remillard  writes:

> The licensing link says the following, it is kind of weird.

indeed.

> "The City of Boston recognizes the value and benefit gained by sharing
> GIS data. Although the City has made reasonable efforts to provide
> accurate data, the City makes no representations or guarantees about
> the accuracy, completeness, or currency of the information provided.
> The City of Boston provides this data as is and with all faults, and
> makes no warranty of any kind. Each user is responsible for
> determining the suitability of the data for their intended use or
> purpose. Neither the City nor its affiliates, employees, or agents
> shall be liable for any loss or injury caused in whole or in part by
> use of any data obtained from this website. The GIS data is updated
> and modified on a regular basis and users are encouraged to report any
> errors to the City."

It's weird because it's not actually a license.  There's no grant of
permission to copy, to make derived works, or to redistribute.

The liability text is also weird, in that it's just an assertion, not a
contract.

Being "encouraged" to report errors is fine.


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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Roman Yepishev]

Hi Jason,

On Mon, 2016-03-21 at 20:42 -0400, Jason Remillard wrote:
> Hi Roman,
> 
> The city of Boston building data set for buildings has address.
> 
> http://bostonopendata.boston.opendata.arcgis.com/datasets/492746f09dd
> e475285b01ae7fc95950e_1
Interesting, so that's where the tax parcel basemap buildings are
coming from...

> It seems like they have already figured out what address goes on what
> building. Should this data set be used rather than the parcel data
> set?
We are not using the parcel data set, instead, we are using a service
build specifically to point to street addresses - http://bostonopendata
.boston.opendata.arcgis.com/datasets/b6bffcace320448d96bb84eabb8a075f_0
 (Live Street Address Management (SAM) Addresses), which is, well, live
and appears to have changed every time I fetched the geojson feed.
 
> The licensing link says the following, it is kind of weird.
> 
> "The City of Boston recognizes the value and benefit gained by
> sharing GIS data. ... The GIS data is updated
> and modified on a regular basis and users are encouraged to report
> any errors to the City."

At some point I found a notice that since the data was paid for by the
taxpayers, it is freely available to the public. I hope I'll meet
someone from MassGIS this week to clarify the statement above.

> I suggest that you move forward with the building splitting, since it
> is a manual process, it can proceed like a normal mapping activity.
Yup, that's what I am doing now.

> While the buildings are being cut up, we can work on address import
> and make sure it is good shape.  Before I would be comfortable with
> the import, I would like to see some sample OSM files we can load
> into JOSM to look over.
I have been regenerating the .osc files daily (new batch in an hour)
when new data is available or the code is optimized. All the files are
linked to from the wiki page - https://wiki.openstreetmap.org/wiki/Impo
rt/Boston_Street_Address_Management_%28SAM%29_Import#OSM_Data_Files.
I'd like to point out that only -unique.osc are considered for import,
the -fixmes.osc are for further investigation and additional
processing.

As per the "Buildings" dataset you mentioned above, that does look like
a good source, but I did a spot-check on various buildings I've
surveyed:
* Object ID: 91094 - no house number (should be 32-36 John A
Andrew Street)
* Object 90372 - 110 McBride (should be 108-110) - and
generally building ranges are missing, so there are e.g. 5 "378
Riverway"s since they are located on the same parcel.

The geometry information, however, looks very yummy. It's not directly usable 
since the various building parts are provided as separate objects probably 
linked to by the BUILDING_I. Now, if we at some point decide to replace the 
Boston geometry information, that would be a great dataset. But I feel this is 
far more involved than adding the house numbers for basic navigation needs 
which is what I am after. And even if we do, there are newer shapefiles based 
on Orthoimagery/LIDAR which has the newer building shapes, and geometry is 
completely different, buildings are not split and have no addresses.

-- 
Sincerely,
Roman

signature.asc
Description: This is a digitally signed message part
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Jason Remillard]

Hi Roman,

The city of Boston building data set for buildings has address.

http://bostonopendata.boston.opendata.arcgis.com/datasets/492746f09dde475285b01ae7fc95950e_1

It seems like they have already figured out what address goes on what
building. Should this data set be used rather than the parcel data
set?

The licensing link says the following, it is kind of weird.

"The City of Boston recognizes the value and benefit gained by sharing
GIS data. Although the City has made reasonable efforts to provide
accurate data, the City makes no representations or guarantees about
the accuracy, completeness, or currency of the information provided.
The City of Boston provides this data as is and with all faults, and
makes no warranty of any kind. Each user is responsible for
determining the suitability of the data for their intended use or
purpose. Neither the City nor its affiliates, employees, or agents
shall be liable for any loss or injury caused in whole or in part by
use of any data obtained from this website. The GIS data is updated
and modified on a regular basis and users are encouraged to report any
errors to the City."

I suggest that you move forward with the building splitting, since it
is a manual process, it can proceed like a normal mapping activity.
While the buildings are being cut up, we can work on address import
and make sure it is good shape.  Before I would be comfortable with
the import, I would like to see some sample OSM files we can load into
JOSM to look over.

Jason


On Sun, Mar 20, 2016 at 2:52 PM, Roman Yepishev  wrote:
> Hi, all! Going back to the point...
>
> I stopped linking to the .osn files in order to minimize the confusion.
>
> Instead, every neighborhood gets their .gpx file with the details of
> the issues encountered at that particular address:
>  - Building is missing.
>  - Building has more than one address.
>  - Building has a street name that is not known to OSM or has not been
> added to the mapping.
>
> This will allow locating the issues quicker while surveying.
>
> I have also generated the .pbf file containing the last export of US,
> MA from Geofabrik + unique house numbers. Since I am using OsmAnd, I
> have also generated the .obf map. Basically, that's how OSM would look
> like if the current list of changes is applied.
>
> https://wiki.openstreetmap.org/wiki/Import/Boston_Street_Address_Manage
> ment_%28SAM%29_Import#OSM_Data_Files
>
> There was a question of the data accuracy earlier - I've spent the last
> 3 days spot-checking the building numbers and I have to say they are
> pretty accurate. Some buildings, however, have picked one number from
> the range assigned, and this will have to be rectified manually as
> well. The data from Boston Tax Parcel may help with that, but it's
> license is not completely clear.
>
> I found a couple of issues while generating the datasets/surveying the
> locations:
>  * Some of the addresses from MassGIS point to parks, monuments, or
> buildings are located a few feet away. While it may possible to assign
> the marker to the building nearby, I'd prefer not to do the guess work
> and leave it for refining in the future.
>  * Original OSM street names must have been imported from MassGIS
> roads, and a few of these don't correspond to the signs (something as
> minor as Conry Crescent Street vs Conry Crescent or slightly more
> interesting Glenvale Terrace vs Chestnut Terrace). So there are
> clusters of buildings in .gpx file pointing to possible street naming
> issues, which will have to be manually correlated with the signs on the
> streets.
>  * Multipolygon buildings are not supported by my script, so there will
> be up to 48 'missing building' false positives for the whole Boston.
>
> Overall, I feel pretty good about the quality of the data and would
> like to hear more about issues that I may have missed.
>
> --
> Sincerely,
> Roman Yepishev
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>

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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Clifford Snow]

On Sun, Mar 20, 2016 at 11:52 AM, Roman Yepishev 
wrote:

>  * Some of the addresses from MassGIS point to parks, monuments, or
> buildings are located a few feet away. While it may possible to assign
> the marker to the building nearby, I'd prefer not to do the guess work
> and leave it for refining in the future.
>

I used a 5 meter rule when conflating outlines and addresses. If the
address was within 5 meters I assigned it to the outline. The next time I
do an address import I'm going to refine that to first check that the
address and building are in the same parcel.

We imported addresses for parks and other such features. My experience is
that someone with a park address would like to be routed to the address.
You could manually position the address node at the main parking lot.


-- 
@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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Roman Yepishev]

Hi, all! Going back to the point...

I stopped linking to the .osn files in order to minimize the confusion.

Instead, every neighborhood gets their .gpx file with the details of
the issues encountered at that particular address:
 - Building is missing.
 - Building has more than one address.
 - Building has a street name that is not known to OSM or has not been
added to the mapping.

This will allow locating the issues quicker while surveying.

I have also generated the .pbf file containing the last export of US,
MA from Geofabrik + unique house numbers. Since I am using OsmAnd, I
have also generated the .obf map. Basically, that's how OSM would look
like if the current list of changes is applied.

https://wiki.openstreetmap.org/wiki/Import/Boston_Street_Address_Manage
ment_%28SAM%29_Import#OSM_Data_Files

There was a question of the data accuracy earlier - I've spent the last
3 days spot-checking the building numbers and I have to say they are
pretty accurate. Some buildings, however, have picked one number from
the range assigned, and this will have to be rectified manually as
well. The data from Boston Tax Parcel may help with that, but it's
license is not completely clear.

I found a couple of issues while generating the datasets/surveying the
locations:
 * Some of the addresses from MassGIS point to parks, monuments, or
buildings are located a few feet away. While it may possible to assign
the marker to the building nearby, I'd prefer not to do the guess work
and leave it for refining in the future.
 * Original OSM street names must have been imported from MassGIS
roads, and a few of these don't correspond to the signs (something as
minor as Conry Crescent Street vs Conry Crescent or slightly more
interesting Glenvale Terrace vs Chestnut Terrace). So there are
clusters of buildings in .gpx file pointing to possible street naming
issues, which will have to be manually correlated with the signs on the
streets.
 * Multipolygon buildings are not supported by my script, so there will
be up to 48 'missing building' false positives for the whole Boston.

Overall, I feel pretty good about the quality of the data and would
like to hear more about issues that I may have missed.

-- 
Sincerely,
Roman Yepishev

signature.asc
Description: This is a digitally signed message part
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Greg Troxel]

I should point out that I'm not opposed to this import or address
imports in general; generally, I am supportive.  But, I think the doing
an import right is vastly harder than someone who hasn't been through
one thinks, and that it's good to iterate on approach and data quality,
and not rush or have a deadline/planned completion time.

These comments are partly based on the Mass buildings import, which I
think was hugely successful.  The data was spot checked by lots of
people and found to be very good, it was added in a way which avoided
changing any hand-mapped data, it's led to mapping missing subdivisions,
and we've had basically zero reports of problems from it.


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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Roman Yepishev]

Hi Greg, all.

I'd like to provide some information on the import I did not share
initially to make my intentions clear (so far I may be seen as dumping
the data into OSM and running away).

TL;DR
=

* I believe in an iterative approach to any project.
* I want to make as many useful things as possible in the limited time
I have. I want a strict deadline to mark the end of my active
involvement and enable others to pick up without creating conflicts.
* I want to improve the routing and location information for me and for
others.
* I have never wanted to introduce buildings with fixme in them into
OSM, I will not import notes.
* I will import data, fix buildings with issues, regenerate the data,
rinse, repeat.
* I will not overwrite the existing building numbers.
* All the scripts I'm using are in public domain.

Long version


My background
-

First of all, I'm a development/operations guy with mostly web service
background, and iterative approach to anything is basically the only
way to do things there. Additionally I took part in a number of
proprietary and open-source projects where the lack of completion
deadlines forced the project to be ready when it is ready. Sometimes
never.

Motivation
--

  As I was walking around Boston using OsmAnd, I would often fail to
locate the venues just because there were no building numbers on the
street I'm supposed to go to. Now, I can still go along the street, but
a number of times I got confused because the block no longer looked
like it used to with the redevelopment going on. The only way is to
bruteforce, expecting that the buildings will be in order. Building
numbers "14 1/2" or "38R" are hard to locate unless you've been there
already.
  As a novice driver I find lack of numbers and details also daunting,
leaving me with no choice but to use Google Maps/Here maps, since I
need to scan building numbers (sometimes located under a rock) as I am
going.

Rushing with a deadline
---

  Again, based on my involvement with various open-source projects, it
is sometimes impossible to get anything vetted unless motivation is
strong and a sense of urgency is introduced. I have to apologize for
that here, as I should have explained it better in my first message.

Importing artifacts
---

  My plan has always been to:

  1. Import unique buildings.
  2. Regenerate a set of .osc, .osn files, post them to wiki for review
(if somebody wants to look at them)
  3. Upload ONLY unique buildings into OSM (no fixmes, no notes, etc.).
  4. Modify the rest of buildings so that they become unique (if
possible, if not - skip them)
  5. Add missing buildings, verify they are unique.
  6. Repeat from 2.

I will add this information to the wiki.

Iterations
--

The import will have to go through multiple iterations. At first I will
import ONLY buildings that are already good to go and require no manual
interaction. The quality of building polygons vary, and it may take
much more time to reach 100% coverage (we may not even be able to reach
it at all due to a changing nature of the cities), but marking 90%
buildings will make locating the missing ones much easier.

As I am trying to use OsmAnd more on my phone I find that presence of a
lot of "height estimated" fixmes in Downtown Boston (you can enable OSM
map helper) makes the map unreadable. Again, the -fixmes.osc files that
you see in the wiki page are just for finding issues with existing
buildings:
 - more than one addresses for a single building.
 - address is already provided, but differs from what the city expects
it to be (e.g. 90 South St, Boston, MA - "Farnsworth House" has to be
#100 according to two city sources, but the sign says #90, so it is #90
in OSM - https://www.openstreetmap.org/way/29939006 - I am planning to
resurvey the 90-86 building above that.) I don't want to overwrite
other people's hand-entered data, but I want to be able to see where
the conflicts are.

The notes must and will not be imported. They will be periodically
regenerated so that it is possible to see how the OSM updates go
(missing buildings added, existing buildings split).

Tools
-

All the python/SQL scripts I am using to create the datasets are
already available on bitbucket. You can perform the steps mentioned in
README and you will end up with the same results as mine. I am yet to
add the license text there, they are in a public domain.

Please note the scripts originated from two all-nighters and I am
refining them as I go.

Closing statement
-

What I hope to accomplish is to make the routing work better for me,
and as a great side effect, these changes will make OSRM pick the right
buildings (or approximate locations), the search for the building in
Nominatim will yield results instead of finding everything but the
thing I searched for, and I am sure this will benefit the community as
well.

Before involvement with OSM I treated the routing 

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Jason Remillard]

Hi Roman ,

- The source addresses uses abbreviations (RD, ST,etc)  are you expanding them?
- The source addresses are capitalized, are you fixing that?
- How are you dealing with multiple addresses per building
- How are you dealing with multiple buildings per address.
- Unless you are working full time on this two weeks seems like not
enough time, it is 380,000 addresses.
- The source data contains the building heights, you might want to
import that in too.
- I would like to see a sample osm/osc files.

Thanks
Jason



On Tue, Mar 15, 2016 at 12:52 PM, Roman Yepishev  wrote:
> (re-posting to both mailing lists since I failed to subscribe to
> imports@ before sending)
>
> Hello OpenStreetMap folks,
>
> TL;DR: import wiki page: https://wiki.openstreetmap.org/wiki/Import/Bos
> ton_Street_Address_Management_%28SAM%29_Import
>
> Boston, Massachusetts is relatively well mapped, however the buildings
> usually lack addr:housenumber and addr:street tags.
>
> Since the city is not built on a grid-based design, the streets can
> wander around making finding the right house with OpenStreetMap a
> challenge. City of Boston provides a sizable amount of data via Open
> Government initiative. One of the things available freely is a Live
> Street Address Management (SAM) dataset[1] that identifies the location
> of the buildings on the map. We can use that.
>
> As requested by Guidelines[2], I am writing to imports@ and talk-us@ to
> discuss the outlined import procedure for the data. I will be driving
> the generation, upload, and validation.
>
> The wiki page contains the data on all the neighborhoods (sans 2 that
> for some reason did not create a polygon - I'm investigating that), so
> you can load it locally and see what's going to happen. Please do not
> upload these changes.
>
> My username is 'ryebread' on OSM, User:Rye on OSM Wiki.
>
> [1]: http://www.cityofboston.gov/open/
> [2]: https://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> --
> Sincerely,
> Roman Yepishev
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>

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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Roman Yepishev]

Quick followup as I may have had the Tax Parcel 2015 dataset in mind.

On Wed, 2016-03-16 at 08:57 -0400, Roman Yepishev wrote:
> 
> > - The source data contains the building heights, you might want to
> > import that in too.
> Only number of floors is provided (which can be 2.5), not the height
> itself. It is easy to add this though. My initial reading of https://
> wi
> ki.openstreetmap.org/wiki/Key:building:levels suggested that
> building:levels is not useful w/o height.

There is no building height in http://bostonopendata.boston.opendata.ar
cgis.com/datasets/b6bffcace320448d96bb84eabb8a075f_0, sorry about that.

signature.asc
Description: This is a digitally signed message part
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Greg Troxel]

Roman Yepishev  writes:

> The wiki now contains updated files that set the postcode and add
> a fixme tag to a building in case it already had the number that does
> not match the official information from SAM.

How many fixme tags would there be?
How many of these fixme tags have you field-checked?
For what fraction of them were the city data correct?

This is a serious question; we know most MassGIS data is right, but we
haven't qualified the city db yet.



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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Greg Troxel]

Clifford Snow  writes:

> 4) Is it really necessary to upload that many notes during the import? if a
> building is missing, can you add a node with the address information
> instead of leaving a note?

I am opposed to adding notes from bulk data.  There are already a lot,
and when they are from a human, that's fine.  But database-generated
notes are spam.

Publishing scripts to generate local notes about a data source for those
who want to look sounds good - without changing the map db or notes db.





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

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Roman Yepishev]

Hi Jason,

Thanks for you message. Replies are inline.

On Wed, 2016-03-16 at 08:02 -0400, Jason Remillard wrote:
> Hi Roman ,
> 
> - The source addresses uses abbreviations (RD, ST,etc)  are you
> expanding them?
There are only around 240 SAM streets that did not map to OSM streets
exactly, these are now being manually added to the mapping table.

> - The source addresses are capitalized, are you fixing that?
Hm, source addresses are not capitalized, I am using the STREET_BODY +
STREET_FULL_SUFFIX as a street name.

"STREET_NUMBER":"72",
"FULL_STREET_NAME":"Addington Rd",
"STREET_ID":27,"STREET_PREFIX":" ",
"STREET_BODY":"Addington",
"STREET_SUFFIX_ABBR":"Rd",
"STREET_FULL_SUFFIX":"Road",
"STREET_NUMBER_SORT":72,
"MAILING_NEIGHBORHOOD":"West Roxbury"
"ZIP_CODE":"02132"


> - How are you dealing with multiple addresses per building
I am adding a local note highlighting that the the same way has more
than one address to locate buildings that need to be split according to
parcel map/retrace from Bing/MassGIS Orthoimagery. Such buildings are
generated into separate -fixmes.osc files.

> - How are you dealing with multiple buildings per address.
Since only a single location is provided for a building
(RELATION_TYPE=1) there is no multiple matching buildings per address.
On a side note that may require additional survey on location in case a
multipolygon is required. We can't deduce that from the source data.

> - Unless you are working full time on this two weeks seems like not
> enough time, it is 380,000 addresses.
Please see the wiki page linked - https://wiki.openstreetmap.org/wiki/I
mport/Boston_Street_Address_Management_(SAM)_Import there are about
5000 with issues out of 64K existing OSM buildings (~8%). At least
until those two missing neighborhoods are found.

Even if only unique buildings are imported it will yield a 92% increase
of accuracy for building locations. The remaining time will be spent
tweaking these 5000 buildings. And yes, I'm basically working on this
full time.

> - The source data contains the building heights, you might want to
> import that in too.
Only number of floors is provided (which can be 2.5), not the height
itself. It is easy to add this though. My initial reading of https://wi
ki.openstreetmap.org/wiki/Key:building:levels suggested that
building:levels is not useful w/o height.

> - I would like to see a sample osm/osc files.
The .osc and .osn files can be found here - they are periodically
regenerated as I am fixing the transformation scripts
https://wiki.openstreetmap.org/wiki/Import/Boston_Street_Address_Manage
ment_(SAM)_Import

> 
> Thanks
> Jason
> 
> 
> 
> On Tue, Mar 15, 2016 at 12:52 PM, Roman Yepishev  > wrote:
> > 
> > (re-posting to both mailing lists since I failed to subscribe to
> > imports@ before sending)
> > 
> > Hello OpenStreetMap folks,
> > 
> > TL;DR: import wiki page: https://wiki.openstreetmap.org/wiki/Import
> > /Bos
> > ton_Street_Address_Management_%28SAM%29_Import
> > 
> > Boston, Massachusetts is relatively well mapped, however the
> > buildings
> > usually lack addr:housenumber and addr:street tags.
> > 
> > Since the city is not built on a grid-based design, the streets can
> > wander around making finding the right house with OpenStreetMap a
> > challenge. City of Boston provides a sizable amount of data via
> > Open
> > Government initiative. One of the things available freely is a Live
> > Street Address Management (SAM) dataset[1] that identifies the
> > location
> > of the buildings on the map. We can use that.
> > 
> > As requested by Guidelines[2], I am writing to imports@ and talk-
> > us@ to
> > discuss the outlined import procedure for the data. I will be
> > driving
> > the generation, upload, and validation.
> > 
> > The wiki page contains the data on all the neighborhoods (sans 2
> > that
> > for some reason did not create a polygon - I'm investigating that),
> > so
> > you can load it locally and see what's going to happen. Please do
> > not
> > upload these changes.
> > 
> > My username is 'ryebread' on OSM, User:Rye on OSM Wiki.
> > 
> > [1]: http://www.cityofboston.gov/open/
> > [2]: https://wiki.openstreetmap.org/wiki/Import/Guidelines
> > 
> > --
> > Sincerely,
> > Roman Yepishev
> > 
> > ___
> > Imports mailing list
> > impo...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/imports
> > 


signature.asc
Description: This is a digitally signed message part
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Roman Yepishev]

Hi Clifford, thank you for the message. The answers are inline below.

On Tue, 2016-03-15 at 13:40 -0700, Clifford Snow wrote:

> 1.) Automatically updating the street name to match the address
> records is not advisable. My experience doing address imports, the
> address information may not match the street signs. There may be two
> different departments responsible for the information, accessor and
> highway/street department. 

OK, that's a valid point. I will not overwrite the street info based on
punctuation differences since then the MassDOT names will no longer
match.

> 2.) Is there addr:city and addr:postcode information available to add
> with the import?
Actually yes, there is the zip_code field in the source data. The city
is Boston for all these buildings.

I assumed that a ZIP code information is handled by some relation, and
not attached to the building. Just read about addr:postcode on wiki and
I don't see a reason why that can't be added to the buildings while we
are at it.

> 
> 3) Just looking at one neighborhood, Allston-Brighton, the .osc
> contains building=yes. Does that mean if a building outline is tagged
> building=residential or any other building tag it will be retagged
> building=yes?
The selection runs on anything that has a tag key building  (and value
is not 'no', just in case). No change of building type will be
performed.

> 4) Is it really necessary to upload that many notes during the
> import? if a building is missing, can you add a node with the address
> information instead of leaving a note?
I should have been clear on that - the notes generated are not designed
to be uploaded at all. It's just the only way I found that I can put a
marker on the map and be able to see it in JOSM without creating a POI.

I have updated the wiki page with the above clarifications.

-- 
Sincerely,
Roman

signature.asc
Description: This is a digitally signed message part
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Boston, MA, USA addr:housenumber Import

[Clifford Snow]

Glad to see someone adding more addresses to OSM.

I have some questions/comments for you.

1.) Automatically updating the street name to match the address records is
not advisable. My experience doing address imports, the address information
may not match the street signs. There may be two different departments
responsible for the information, accessor and highway/street department.

2.) Is there addr:city and addr:postcode information available to add with
the import?

3) Just looking at one neighborhood, Allston-Brighton, the .osc contains
building=yes. Does that mean if a building outline is tagged
building=residential or any other building tag it will be retagged
building=yes?

4) Is it really necessary to upload that many notes during the import? if a
building is missing, can you add a node with the address information
instead of leaving a note?

Clifford

On Tue, Mar 15, 2016 at 9:52 AM, Roman Yepishev  wrote:

> (re-posting to both mailing lists since I failed to subscribe to
> imports@ before sending)
>
> Hello OpenStreetMap folks,
>
> TL;DR: import wiki page: https://wiki.openstreetmap.org/wiki/Import/Bos
> ton_Street_Address_Management_%28SAM%29_Import
>
> Boston, Massachusetts is relatively well mapped, however the buildings
> usually lack addr:housenumber and addr:street tags.
>
> Since the city is not built on a grid-based design, the streets can
> wander around making finding the right house with OpenStreetMap a
> challenge. City of Boston provides a sizable amount of data via Open
> Government initiative. One of the things available freely is a Live
> Street Address Management (SAM) dataset[1] that identifies the location
> of the buildings on the map. We can use that.
>
> As requested by Guidelines[2], I am writing to imports@ and talk-us@ to
> discuss the outlined import procedure for the data. I will be driving
> the generation, upload, and validation.
>
> The wiki page contains the data on all the neighborhoods (sans 2 that
> for some reason did not create a polygon - I'm investigating that), so
> you can load it locally and see what's going to happen. Please do not
> upload these changes.
>
> My username is 'ryebread' on OSM, User:Rye on OSM Wiki.
>
> [1]: http://www.cityofboston.gov/open/
> [2]: https://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> --
> Sincerely,
> Roman Yepishev
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
>


-- 
@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

Re: [Talk-us] [Imports-us] Virginia Beach, Virginia Imports

[Jonah Adkins]

Hello,

Thanks for the questions!

> You live an hour away from Virginia Beach, is that correct?


Yes! Good detective work - depending on traffic.

> Are you
> familiar enough with the city to verify the data quality, or will you
> enlist the help of local mappers who are?


Yes! Virginia Beach is part of the Hampton Roads 
 Region, which i’ve lived in for 
awhile.

> Is there a community that can be counted on to make sure the data
> doesn't rot in OSM once imported - or will you commit to that?

I’m committed! 

> Is this import proposal linked to this endeavour in any way?

No.

> On Mar 2, 2016, at 2:58 AM, Frederik Ramm  wrote:
> 
> Hi,
> 
> On 03/02/2016 02:55 AM, Jonah Adkins wrote:
>> I'd like to propose an import of city-sourced GIS data for the City of 
>> Virginia Beach, Va. The City GIS Office has given the data / license for 
>> this purpose.
>> Conflation will be done carefully by hand, and attributes copied where 
>> needed.
> 
> You live an hour away from Virginia Beach, is that correct? Are you
> familiar enough with the city to verify the data quality, or will you
> enlist the help of local mappers who are?
> 
> To quote stevea from teh recent Adirondack thread,
> 
>> Likewise.  We (OSM volunteers) don't often talk about the importance 
>> of KEEPING UP the map after an import, but doing so is a seriously 
>> crucial component. 
> 
> Is there a community that can be counted on to make sure the data
> doesn't rot in OSM once imported - or will you commit to that?
> 
> On http://paidmappers.github.io/home/, you advertise your services as
> mapper-for-hire ("Open Data is growing at an alarming rate and we shall
> put all that data in OpenStreetMap. ...  we scour open data portals and
> sites for authorative data like buildings, public amenities, and
> addresses.") - Is this import proposal linked to this endeavour in any way?
> 
> (I haven't looked at the data and license yet.)
> 
> Bye
> Frederik
> 
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
> 
> ___
> Imports-us mailing list
> imports...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports-us

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

Re: [Talk-us] [Imports-us] Virginia Beach, Virginia Imports

[Tod Fitch]

> On Mar 1, 2016, at 11:58 PM, Frederik Ramm  wrote:
> 
> 
> Is there a community that can be counted on to make sure the data
> doesn't rot in OSM once imported - or will you commit to that?
> 

Is this really a serious objection?

If so then perhaps I should not map areas I visit as I might not visit there 
again and maybe the data will “rot”. I recently moved, should I worry about the 
thousands of objects I mapped in near my old home rotting because I am no 
longer there to maintain things as changes occur?

I think the issue is more how good the data is and how well it is imported: 
Cleaning up bad data is a pain and can discourage new mappers in an area. It 
certainly put me off when I first looked at OSM as the Tiger data in my 
neighborhood was dreadful. I only really to started in mapping a few years 
later once others had done enough cleanup that I could see things were possible 
to bring into a semblance of correctness. But if the imported data is good and 
the import well done, it seems to me that local mappers would have no issue 
updating it as changes occur in the real world. And if there are no mappers 
local to the area, is an empty map better than one with correct data that is 
slowly aging as features change in the real world?

I did help on one address and building import in the city next to the one I 
lived in, but the vast majority of my edits have been from direct survey with 
editing assistance from Bing or Mapbox satellite imagery. Even though I live in 
an area where the government GIS data is by law public domain, I haven’t 
bothered to see what might be available: I spend lots of hours walking streets 
collecting data. So, by inclination I prefer mapping in person rather than 
imports. But this argument against imports seems spurious to me.

Cheers,
Tod



smime.p7s
Description: S/MIME cryptographic signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports-us] Virginia Beach, Virginia Imports

[Frederik Ramm]

Hi,

On 03/02/2016 02:55 AM, Jonah Adkins wrote:
> I'd like to propose an import of city-sourced GIS data for the City of 
> Virginia Beach, Va. The City GIS Office has given the data / license for this 
> purpose.
> Conflation will be done carefully by hand, and attributes copied where needed.

You live an hour away from Virginia Beach, is that correct? Are you
familiar enough with the city to verify the data quality, or will you
enlist the help of local mappers who are?

To quote stevea from teh recent Adirondack thread,

> Likewise.  We (OSM volunteers) don't often talk about the importance 
> of KEEPING UP the map after an import, but doing so is a seriously 
> crucial component. 

Is there a community that can be counted on to make sure the data
doesn't rot in OSM once imported - or will you commit to that?

On http://paidmappers.github.io/home/, you advertise your services as
mapper-for-hire ("Open Data is growing at an alarming rate and we shall
put all that data in OpenStreetMap. ...  we scour open data portals and
sites for authorative data like buildings, public amenities, and
addresses.") - Is this import proposal linked to this endeavour in any way?

(I haven't looked at the data and license yet.)

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

Re: [Talk-us] [Imports-us] RFC: LA County building import

[Alan McConchie]

Hi Frederik,

> On Feb 12, 2016, at 11:33 PM, Frederik Ramm  wrote:
> 
> How many of your team are local to LA, and how are you cooperating with
> the OSM community in LA?

Of the four of us who have been preparing the data and who will be overseeing 
the import, two of us (Omar Ureta and Jon Schleuss) live and work in LA. One of 
us (myself) lived in LA in the past and travels there often for work. The 
fourth (Maning) doesn't live in LA.

We've got connections in the OSM and geospatial community in LA, especially 
through the local Maptime chapter which is one of the largest and most active 
chapters. We haven't started our outreach process in earnest yet, but we have 
github issues to track that, see: [0] and [1]

We consider this email to talk-us as the start of our outreach. 

> What is your estimate about participation of local mappers? Is it likely
> that we'll see 10 people participating, half of them not even living in
> the area, and each of them importing 300,000 of the 3 million buildings?
> 
> That would be my main fear about this; it is not unheard of for previous
> building footprint imports in the US to be called a "community import"
> but the community was really a very eager one-digit number of people who
> mostly didn't even have any ties to the area they were importing in.
> 
> Can we have the hope that the LA building footprint import will be
> handled by people who have actually been to the area they see on their
> editor screen?

We understand your concern. We are involving local mappers as much as possible 
through:

• organizing mapping events with a variety local mapping groups [0]
• contacting local OSM contributors via OSM.org [1]
• allowing local mappers to define areas where they don't want data 
imported [2]

> Will there be people participating in this community import as part of
> their day job?

Yes, the Mapbox data team [3] will assist, but we're going to make sure that 
the local OSM community is equally involved, and that we use this as an 
opportunity to grow the local OSM community on the ground. We have assurances 
that the Mapbox team will keep pace with the local mappers and not overtake 
them. If it takes us a long time to get local mappers involved, then the Mapbox 
team will back off and wait until the locals catch up.

We're not exactly sure how we're going to negotiate the balance of labor, and 
we're open to suggestions on how we can do this well. One possible idea is to 
divvy up the tasks in a kind of checkerboard pattern, with one group of tasks 
set aside for locals only. This way we could make sure that the Mapbox team and 
the local mappers are working side-by-side and checking each others' work.

Also note that the Mapbox Data Team had already started tracing buildings in LA 
County [4] and they agreed to stop that effort and instead join this manual 
import process. So I think that having the Mapbox team involved in the import 
is a better outcome than having them trace all the buildings without any local 
involvement, which would've been the alternative.

Alan



[0] https://github.com/osmlab/labuildings/issues/39
[1] https://github.com/osmlab/labuildings/issues/1
[2] https://github.com/osmlab/labuildings/issues/37
[3] http://wiki.openstreetmap.org/wiki/Mapbox#Mapbox_Data_Team
[4] https://github.com/mapbox/mapping/issues/148
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports-us] RFC: LA County building import

[Frederik Ramm]

Maning,

On 02/13/2016 06:45 AM, maning sambale wrote:
> We are proposing a building import of the public domain building and
> assessor data for LA County [0].

How many of your team are local to LA, and how are you cooperating with
the OSM community in LA?

What is your estimate about participation of local mappers? Is it likely
that we'll see 10 people participating, half of them not even living in
the area, and each of them importing 300,000 of the 3 million buildings?

That would be my main fear about this; it is not unheard of for previous
building footprint imports in the US to be called a "community import"
but the community was really a very eager one-digit number of people who
mostly didn't even have any ties to the area they were importing in.

Can we have the hope that the LA building footprint import will be
handled by people who have actually been to the area they see on their
editor screen?

Will there be people participating in this community import as part of
their day job?

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

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

[Clifford Snow]

On Mon, Nov 9, 2015 at 6:40 PM, Andy Wilson 
wrote:

> 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.


JOSM has a "Replace Geometry" tool found in the Util2 plugin that makes it
easy to merge old and new. Each building will have to be reviewed
individually. In some cases, the building in OSM might be newer but lacking
address information. In that case the address information will need to be
copies from the import to the existing building. It's harder, but with 3
year old data it is likely to occur.

Clifford


-- 
@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

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

[Andy Wilson]

On Mon, Nov 9, 2015 at 12:59 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > Am 09.11.2015 um 18:07 schrieb Eric Ladner :
> >
> > 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] [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 
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 :
>> >
>> > 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] [Imports] Importing Tesla Superchargers

[Jack Burke]

In many cases, the sucket:tesla_supercharger is different

So Tesla is calling their supercharger sockets suckets?

How appropriate. 

-jack


On April 13, 2015 4:24:03 PM EDT, Charles Samuels o...@charles.derkarl.org 
wrote:
On Sunday, April 12, 2015 05:33:02 PM Greg Troxel wrote:
 You may actually be right about the likelihood of correctness, and
this
 may lead to an expected value of  0.1 errors per year.  However,
 imports changing data entered by hand is something that crosses a
 cultural bright line, and I find it concerning that you're heading
down
 that path.  I say that as someone who is usually much more on the
 pro-import side.
 
 To stay within OSM norms, the thing to do is leave the existing data
 alone, and publish a list someplace of mismatches.  It's fine to
write
 to the person who added it and explain that there's a mismatch and
ask
 if they are sure.

Ok, I've made a bunch of changes to the code so that I make fewer
changes to 
OSM. Please follow the links in the original email to see the (now
updated) 
OSM changefile.


 
 The other notion in imports is to test  out the process before you do
 it.  Have you run the conflation code against the osm database, and
how
 many cases are there where osm already has a charger station but the
 tags dont' match?

There are 127 such differences, the vast majority of which are the
name tag. 
I have manually checked this differences:

- The name tags I produce are better than the original
- If they're not better, I manually adjust them
- In many cases, the sucket:tesla_supercharger is different, sometimes 
capacity is different too, in all cases, my numbers match Tesla.com's
- A small number of opening_hours tags are wrong in OSM
- The resulting .osm file I produce has the old tags in an XML comment
for 
convenience.
- Going forward I can and will look at new conflicts.

Charles

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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Importing Tesla Superchargers

[Charles Samuels]

On Sunday, April 12, 2015 05:33:02 PM Greg Troxel wrote:
 You may actually be right about the likelihood of correctness, and this
 may lead to an expected value of  0.1 errors per year.  However,
 imports changing data entered by hand is something that crosses a
 cultural bright line, and I find it concerning that you're heading down
 that path.  I say that as someone who is usually much more on the
 pro-import side.
 
 To stay within OSM norms, the thing to do is leave the existing data
 alone, and publish a list someplace of mismatches.  It's fine to write
 to the person who added it and explain that there's a mismatch and ask
 if they are sure.

Ok, I've made a bunch of changes to the code so that I make fewer changes to 
OSM. Please follow the links in the original email to see the (now updated) 
OSM changefile.


 
 The other notion in imports is to test  out the process before you do
 it.  Have you run the conflation code against the osm database, and how
 many cases are there where osm already has a charger station but the
 tags dont' match?

There are 127 such differences, the vast majority of which are the name tag. 
I have manually checked this differences:

- The name tags I produce are better than the original
- If they're not better, I manually adjust them
- In many cases, the sucket:tesla_supercharger is different, sometimes 
capacity is different too, in all cases, my numbers match Tesla.com's
- A small number of opening_hours tags are wrong in OSM
- The resulting .osm file I produce has the old tags in an XML comment for 
convenience.
- Going forward I can and will look at new conflicts.

Charles

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

Re: [Talk-us] [Imports] Importing Tesla Superchargers

[Marc Gemis]

Do you think anybody will do the effort to correct some of the data, when
it will be overwritten again with each update ? That's why people ask not
to overwrite the data automatically.



regards


m

p.s. it's annoying that this is cross-posted on 2 mailing lists, I'm only
subscribed to one of them.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Importing Tesla Superchargers

[Frederik Ramm]

Hi,

On 04/13/2015 10:23 AM, Greg Morgan wrote:
 Oh my goodness.  Once again we have the alleged notion that imports will
 drive off mappers without examining any real data.

No. It appears that you're going off on a tangent without examining the
messages that were written ;)

Until now I can't see anyone who has said don't import the
superchargers, it will drive off mappers. What I see is don't
overwrite existing, manually collected information in an automated
process, and that is, as Greg correctly says, a cultural bright line
that will not be crossed with impunity.

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

Re: [Talk-us] [Imports] Importing Tesla Superchargers

[Greg Morgan]

Oh my goodness.  Once again we have the alleged notion that imports will
drive off mappers without examining any real data. If we look at the
Buckeye Charger we see that fredo_p, a A Hit-and-Run Mapper, added the
original node.  He's still a mapper. Theodin a German mapper added
something. AndiG88 another German mapper added something.  Finally njaard
touched the same node.  The German mappers did nothing different that what
njaard did.  They looked up that there were 8 charging ports on the Tesla
site.  I surveyed the site and see no problem with what has gone on with
this node.  The question I have is should there be eight nodes for each
station since one is required for each parking spot along with a
wall/building for the transformer where the address is located?  The name
issue may not be a factor since you can Google on either the address or
name.  Note that all the mappers involved including me the surveyor are
still mapping.  I am surprised that we did not loose fredo_p--last modifier
of 95 nodes, 16 ways and 0 relationships--with the mapper's first
experience of a node that does not render. I hope that we don't loose
njaard--last modifier of 2,900 nodes, 663 ways, and 30 relationships--over
a node still does not render with a cute little icon.  In may case, I lost
interest in mapping all EV chargers because there's no reward for mapping
them.  There was the reward of finding three of the four types of chargers
used in the US. There was the reward of understanding the problems with
making EV work. Sure the nodes are in the database but I do not experience
the reward of seeing the node on the map like a regular gas station node.
In my view it is not the importers that are killing mappers it is the
cartographers that only show a portion of what can be mapped.
https://www.google.com/search?q=mapbox+sudio+data+projectie=utf-8oe=utf-8#q=buckeye+arizona+tesla+charger
http://www.teslamotors.com/findus/location?place=buckeyesupercharger
http://wiki.openstreetmap.org/wiki/File:Cs_us_tesla_buckeye_charger.png
http://www.openstreetmap.org/node/2776570644/history#map=19/33.44263/-112.55724
http://www.openstreetmap.org/user/fredo_p
http://hdyc.neis-one.org/?fredo_p
http://www.openstreetmap.org/user/Theodin
http://hdyc.neis-one.org/?Theodin
http://www.openstreetmap.org/user/AndiG88
http://hdyc.neis-one.org/?AndiG88
http://www.openstreetmap.org/user/njaard
http://hdyc.neis-one.org/?njaard

I am guessing that this will bounce because I am not on the import list.

HTH,
Greg


On Sun, Apr 12, 2015 at 5:33 PM, Greg Troxel g...@ir.bbn.com wrote:


 Charles Samuels o...@charles.derkarl.org writes:

  On Sunday, April 12, 2015 01:12:12 AM Andy Allan wrote:
   Right now, if a tag doesn't match with supercharge.info, I overwrite
   OSM's.
 
  Could you explain this a bit further? For example, if supercharge.info
  has capacity 6, and I correct this to capacity 8, does your script
  then overwrite my tag and change it back to the incorrect value?
 
  Correct. My intent is that I expect OSM to be no better than
 supercharge.info,
  so for now it's easiest to just overwrite. Then on following runs of it,
 I
  manually investigate the changes made in OSM and reconcile the
 differences.

 You may actually be right about the likelihood of correctness, and this
 may lead to an expected value of  0.1 errors per year.  However,
 imports changing data entered by hand is something that crosses a
 cultural bright line, and I find it concerning that you're heading down
 that path.  I say that as someone who is usually much more on the
 pro-import side.

 To stay within OSM norms, the thing to do is leave the existing data
 alone, and publish a list someplace of mismatches.  It's fine to write
 to the person who added it and explain that there's a mismatch and ask
 if they are sure.

 The other notion in imports is to test  out the process before you do
 it.  Have you run the conflation code against the osm database, and how
 many cases are there where osm already has a charger station but the
 tags dont' match?

 ___
 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 Tesla Superchargers

[Greg Troxel]

Charles Samuels o...@charles.derkarl.org writes:

 On Sunday, April 12, 2015 01:12:12 AM Andy Allan wrote:
  Right now, if a tag doesn't match with supercharge.info, I overwrite
  OSM's.
 
 Could you explain this a bit further? For example, if supercharge.info
 has capacity 6, and I correct this to capacity 8, does your script
 then overwrite my tag and change it back to the incorrect value?

 Correct. My intent is that I expect OSM to be no better than 
 supercharge.info, 
 so for now it's easiest to just overwrite. Then on following runs of it, I 
 manually investigate the changes made in OSM and reconcile the differences.

You may actually be right about the likelihood of correctness, and this
may lead to an expected value of  0.1 errors per year.  However,
imports changing data entered by hand is something that crosses a
cultural bright line, and I find it concerning that you're heading down
that path.  I say that as someone who is usually much more on the
pro-import side.

To stay within OSM norms, the thing to do is leave the existing data
alone, and publish a list someplace of mismatches.  It's fine to write
to the person who added it and explain that there's a mismatch and ask
if they are sure.

The other notion in imports is to test  out the process before you do
it.  Have you run the conflation code against the osm database, and how
many cases are there where osm already has a charger station but the
tags dont' match?


pgpaZFTtXNvGv.pgp
Description: PGP signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Importing Tesla Superchargers

[Charles Samuels]

On Sunday, April 12, 2015 01:12:12 AM Andy Allan wrote:
  Right now, if a tag doesn't match with supercharge.info, I overwrite
  OSM's.
 
 Could you explain this a bit further? For example, if supercharge.info
 has capacity 6, and I correct this to capacity 8, does your script
 then overwrite my tag and change it back to the incorrect value?

Correct. My intent is that I expect OSM to be no better than supercharge.info, 
so for now it's easiest to just overwrite. Then on following runs of it, I 
manually investigate the changes made in OSM and reconcile the differences.

Charles

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

Re: [Talk-us] [Imports] Importing Tesla Superchargers

[Wolfgang Zenker]

* Charles Samuels o...@charles.derkarl.org [150412 22:21]:
 On Sunday, April 12, 2015 01:12:12 AM Andy Allan wrote:
 Right now, if a tag doesn't match with supercharge.info, I overwrite
 OSM's.

 Could you explain this a bit further? For example, if supercharge.info
 has capacity 6, and I correct this to capacity 8, does your script
 then overwrite my tag and change it back to the incorrect value?

 Correct. My intent is that I expect OSM to be no better than 
 supercharge.info, 
 so for now it's easiest to just overwrite. Then on following runs of it, I 
 manually investigate the changes made in OSM and reconcile the differences.

Sounds like the perfect way to drive away mappers, in other words: a pretty
bad idea. Investigating existing differences and reconciling the two data
sets looks like a much better (and acceptable) way to me.

Wolfgang

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

Re: [Talk-us] [Imports] For comment: import of amenity=bicycle_repair_stations

[Bryce Nesbitt]

On Wed, Mar 4, 2015 at 9:34 PM, an UK mapper wrote wrote:
 Way back when, Bryce wrote:
  The locations need local mapping to get the location perfect.

 Are you intending to feed these local changes back to the data source?
 Will the import involve deleting any repair stations in OSM not in the data 
 source - this doesn't seem like a good idea.

A qualified yes to that.

This import uses a script meant for synchronizing a commercial data
set (like a list of ATM's, radar stations, or chain stores)
to OSM.  It prepares a changelist file describing any differences for
human review.

If an item drops out of the company's dataset, the OSM mapper sees
that closure.  Here if Dero racks removes a location it's because the
property owner, their client, told them the site was removed on the
ground.  The human running the script can decide how to react  (e.g.
mirror the deletion in OSM, take no action, move the item to Open
Historical Map, or tag disused:, or fly to the location and check).

In the ATM or radar station case: it's the same thing.  For well run
corporate data sets the list of open stores, ATMs, or whatever is
quite good.  If an item drops out of that data it's because the
location has closed.  But, the human can review it, checking yelp or
seeking other secondary sources or local sources for information.

For this bike tool data set, OSM changes in the USA have already been
sent back to the corporate source:  mostly duplicate data points and
more
precise positioning.  In general at the next sync this causes no
trouble, the fuzzy match is simply less fuzzy, and no action is taken.
Similarly if an item is deleted from the OSM set, a flag will be
raised.  Here the Dero company would be notified.  This has not
happened yet.

The script was built for a one way synchronization, but seems to work
reasonably well for this two way sync.

---
The main challenge is that detecting duplicates is hard, because some
proper stations are literally 60 or so meters apart,
and some positioning errors are of the same magnitude.  Thus the local
mapper who can visit the site and work it all out.

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

Re: [Talk-us] [Imports-us] Rail westerly

[Clifford Snow]

On Wed, Dec 31, 2014 at 11:24 AM, stevea stevea...@softworkers.com wrote:

 I examine these in JOSM right now.  First they need to be unzipped, and it
 looks like the (provided on that web page) PRJ file to change from WGS 84
 (default) to either NAD 27 or 83 projection is required. I haven't done
 that to these data in the instant case, but I've fiddled these before and I
 think it is doable.


Michael,
Thanks for the info!  You always can be counted on to find data, even if it
is obscure.

SteveA,
I'd be happy to convert the shapefile to an .osm file for importing. It
could be broken into smaller chunks to use the tasking manager. Maybe by
county. Someone needs to create a import page on the wiki and announce it
on the import mailing list.

Let me know what you think.

Clifford


-- 
@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