[Imports-us] Import of Parks and Parking areas for Greenville, SC

[Mike N]

Proposing an import for parks and parking areas from GIS data for the 
city of Greenville, SC


https://wiki.openstreetmap.org/wiki/Greenville_SC_City_Parks_Import
https://wiki.openstreetmap.org/wiki/Greenville_SC_City_Parking_Areas_Import

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

Re: [Imports-us] Reply - Importing building outlines from Microsoft building footprints

[Mike N]

On 12/11/2020 11:09 AM, Raymond wrote:
and adding source=* tag is to track if an error or inaccurate found 
later, map reader can easily track the reason to source problem and 
correct it with other objects with same source. And tell other mapper 
what a dataset can used for mapping more area to complete.



   I agree with Alex: source does not belong on objects for an import 
project.   When researching how an object was created, the changeset 
comment is easily available for the entire history.   The changeset 
comment is sufficient to credit the source and point to the imports page.


  (I still don't know if I should delete the source tag - I have edits 
on objects that say 'source=yahoo', which makes no sense in today's 
world and especially on objects which were split or combined).


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

Re: [Imports] Data license checking

[Mike N]

On 9/22/2020 10:50 PM, Andrew Turner wrote:
You should ask the local government to add explicit licenses to their 
open data. They can indicate specific open licenses following these 
directions (since they are using ArcGIS Hub) [1]


As also noted, if they submit their data to Esri Living Atlas they can 
also explicitly indicate ODbL and OSM usage for their data and it would 
then be available in RapiD and can be more easily added to OSM via the 
editor.


  HOPE exists!  They are certainly not going to retain their lawyer for 
several additional days of GIS data license study.   The GIS guy in 
charge already said that his intent was to make the data freely 
available to Bing, Google, and other map consumers to promote economic 
development.


   Because the ArcGIS Hub makes license selection simple, I might be 
able to talk him into selecting a PDDL license which would be even 
better, and that will be OSM usable.


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

[Imports] Data license checking

[Mike N]

If a county runs an open data portal, is this suitable for usage in 
Openstreetmap?



https://pcgis-pickenscosc.opendata.arcgis.com/search?groupIds=28849116eea848b7a883e9aa8c109ca6

  Thanks,

  Mike

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

[Imports] Spartanburg SC Subdivision imports

[Mike N]

Named residential areas import - mostly hand tracing from the vector 
overlay.


https://wiki.openstreetmap.org/wiki/Spartanburg_County_Subdivision_Import

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

[Imports-us] Spartanburg SC Subdivision imports

[Mike N]

Named residential areas import - mostly hand tracing from the vector 
overlay.


https://wiki.openstreetmap.org/wiki/Spartanburg_County_Subdivision_Import

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

[Imports] Spartanburg County SC Microsoft Building and Address import

[Mike N]

This is a proposed import of Microsoft building footprints and address 
points for Spartanburg County SC, based on county GIS data and the 
Microsoft Buildings data.


https://wiki.openstreetmap.org/wiki/Spartanburg_County_Address_And_Building_Import

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

[Imports-us] Spartanburg County SC Microsoft Building and Address import

[Mike N]

This is a proposed import of Microsoft building footprints and address 
points for Spartanburg County SC, based on county GIS data and the 
Microsoft Buildings data.


https://wiki.openstreetmap.org/wiki/Spartanburg_County_Address_And_Building_Import

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

Re: [Imports] Microsoft Buildings Import Inquiry

[Mike N]

Thanks - that's what I was thinking.  Documenting is not too bad, but it 
is inconvenient to use the import account.


On 2/12/2019 12:55 PM, john whelan wrote:
The building outlines to my understanding are not Bing images but have 
to be imported using JOSM or another tool as would any other import so 
to my mind need a formal import plan and agreement with local mappers 
etc. etc.


A mapathon is just a number of mappers who are working together.  They 
may or may not be importing.


Probably not what you wanted to hear and I strongly suspect some have 
been brought into OSM without following the import guidelines.


Cheerio John

On Tue, Feb 12, 2019, 12:41 PM Mike N <mailto:nice...@att.net> wrote:



Checking in - Is the process of using Microsoft Buildings which are
occasionally distorted by shadows and thus all have to be manually
inspected still treated as an import, or would the process be
classified
as a Mapathon?

    Thanks,

    Mike

___
Imports mailing list
Imports@openstreetmap.org <mailto:Imports@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/imports




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

[Imports] Microsoft Buildings Import Inquiry

[Mike N]

Checking in - Is the process of using Microsoft Buildings which are 
occasionally distorted by shadows and thus all have to be manually 
inspected still treated as an import, or would the process be classified 
as a Mapathon?


  Thanks,

  Mike

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

Re: [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.

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

Re: [Imports-us] [Imports] 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.

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

Re: [Imports] [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.


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

[Imports] Spartanburg County SC road centerlines import

[Mike N]

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

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

Re: [Imports] Import cellular towers for Spartanburg County, SC, USA

[Mike N]

https://wiki.openstreetmap.org/wiki/Spartanburg_County_Cell_Tower_Import

  This import is complete.  We quickly noticed that adding the driveway 
to the tower would be very valuable to a technician trying to locate the 
access road.   "Does this dirt path through the trees lead to a random 
farm field, or to the cell tower"?


   As expected, the original data locations varied from nearly on the 
tower to hundreds of meters.Some could not be located on imagery and 
were not imported because they may have been removed.   Having full 
information tags on these towers in OSM will make the data much more useful.



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

Re: [Imports] [talk-au] Public Barbeques in the ACT

[Mike N]

On 10/10/2018 3:37 PM, Kevin Kenny wrote:
In the couple of imports that I curate, I leave external ID's in OSM, to 
give me a quick search for the object that I previously imported. (I can 
then check that the user that last modified the object was the import.)  
If the object has been changed in the external database, and is 
unmodified since the last import, I can skip a manual conflation step, 
and simply apply any changes and present the modified object for review.


The ID's would be useless in a 'one time only' import, but I attempt to 
keep the import up to date as new versions of the external data appear.


   As the OSM community grows in the region containing a curated 
dataset, use cases must be managed:

   OSM user adds a new object they observe.
   OSM user adds a duplicate object without first checking for an 
existing object.

   OSM user removes an object they observe is no longer there.

  It all requires complete conflation, just as if there had been no 
external IDs in the database.


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

Re: [Imports] Import cellular towers for Spartanburg County, SC, USA

[Mike N]

Forward - On Sep 18, 2018, 10:27 AM, < robertaustinb...@protonmail.com> 
wrote:



Hello my name is Austin and I am also in the local community doing 
the import.

I work on cell towers and can answer a few of these questions.

1. Yes they do have a regular street address just like a house.

2. We have looked at satellite imagery for a few and we will looks 
at them all during the import as part of the QA process.


3. Yes it is intentional that there is no stated purpose. Tower 
companies build tower with things in mind but it's really just vertical 
real estate that they will rent for anything. I've seen space rented for 
amateur radio. Also things change on the towers as leases run out, for 
instance T-MOBILE starts using a new frequently and now they need less 
towers in a area and decommission one where they were the only cell 
carrier on the tower but there is still FM on the tower. So listing a 
purpose for the towers even if we could would not be a good idea since 
we could not update them. There are some projects out there to track and 
monitor who is on a tower but that is outside of the scope of this import.


4. Mike might want to add to this one but, That will be made on a 
case by case basis, and I don't think it will be much of a issue as 
Very! few towers in our area are mapped to begin with, I'm sure less 
than 1%.





 -- Back to Mike---


To expand on what Austin mentioned -

  3 - I did overlook the tower:type tag, and have added that tag to the 
data now.
  4.  The existing data has one tag conflict, but I believe the new tag 
conforms to OSM standards (tower:type=pole instead of the more common 
tower:type=freestanding).


  Regards,

  Mike

On 9/18/2018 3:42 AM, Mateusz Konieczny wrote:

Thanks for good import documentation!

1. Are you sure that these towers have addr:housenumber?
2. Have you checked at least some masts/water towers
  to confirm that official data is correct?
3. Is it deliberate that tower purpose is not mentioned in the imported 
data?
4. Is it a good idea to overwrite data on existing objects by new data 
in cases

  where tags conflict (point 6 of workflow will lead to that)?


16. Sep 2018 19:26 by nice...@att.net :


Proposing an import for 122 Cellular Towers (and merge tags with 7
existing towers in OSM). Plan is at

https://wiki.openstreetmap.org/wiki/Spartanburg_County_Cell_Tower_Import


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



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




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

Re: [Imports-us] [Imports] Import cellular towers for Spartanburg County, SC, USA

[Mike N]

Forward - On Sep 18, 2018, 10:27 AM, < robertaustinb...@protonmail.com> 
wrote:



Hello my name is Austin and I am also in the local community doing 
the import.

I work on cell towers and can answer a few of these questions.

1. Yes they do have a regular street address just like a house.

2. We have looked at satellite imagery for a few and we will looks 
at them all during the import as part of the QA process.


3. Yes it is intentional that there is no stated purpose. Tower 
companies build tower with things in mind but it's really just vertical 
real estate that they will rent for anything. I've seen space rented for 
amateur radio. Also things change on the towers as leases run out, for 
instance T-MOBILE starts using a new frequently and now they need less 
towers in a area and decommission one where they were the only cell 
carrier on the tower but there is still FM on the tower. So listing a 
purpose for the towers even if we could would not be a good idea since 
we could not update them. There are some projects out there to track and 
monitor who is on a tower but that is outside of the scope of this import.


4. Mike might want to add to this one but, That will be made on a 
case by case basis, and I don't think it will be much of a issue as 
Very! few towers in our area are mapped to begin with, I'm sure less 
than 1%.





 -- Back to Mike---


To expand on what Austin mentioned -

  3 - I did overlook the tower:type tag, and have added that tag to the 
data now.
  4.  The existing data has one tag conflict, but I believe the new tag 
conforms to OSM standards (tower:type=pole instead of the more common 
tower:type=freestanding).


  Regards,

  Mike

On 9/18/2018 3:42 AM, Mateusz Konieczny wrote:

Thanks for good import documentation!

1. Are you sure that these towers have addr:housenumber?
2. Have you checked at least some masts/water towers
  to confirm that official data is correct?
3. Is it deliberate that tower purpose is not mentioned in the imported 
data?
4. Is it a good idea to overwrite data on existing objects by new data 
in cases

  where tags conflict (point 6 of workflow will lead to that)?


16. Sep 2018 19:26 by nice...@att.net :


Proposing an import for 122 Cellular Towers (and merge tags with 7
existing towers in OSM). Plan is at

https://wiki.openstreetmap.org/wiki/Spartanburg_County_Cell_Tower_Import


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



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




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

[Imports] Import cellular towers for Spartanburg County, SC, USA

[Mike N]

Proposing an import for 122 Cellular Towers (and merge tags with 7 
existing towers in OSM).   Plan is at


https://wiki.openstreetmap.org/wiki/Spartanburg_County_Cell_Tower_Import


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

Re: [Imports] ebike charging stations for DE & AUT

[Mike N]

On 8/15/2018 4:18 AM, Joachim Kast wrote:

According to the Google Geocoding API Policies [2] coordinates
determined in this way may only be displayed on a Google map. This is
not compatible with the OpenStreetMap Contributor Terms [3].

It is therefore impossible to import the 2000 bike-energy charging
stations into OSM.


  If some of the stations have addresses in OSM, perhaps those could be 
imported with a position used from OSM?   There might still be a 
question of whether they are located in a building or outside facing a 
street.


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

Re: [Imports] Bing Building Import

[Mike N]

On 7/4/2018 12:10 AM, Greg Morgan wrote:

However, a nice square build is always a good start.


 Somewhat related - a local prolific mapper added about 7k+ buildings 
as squares and rectangles.   That was the early days, and I wondered if 
I was doing it wrong by trying to get too detailed on buildings.


  Were our feet wounded by this data?  No, the buildings are there to 
be improved on by the next mapper, possibly from the MS Building data 
via "replace geometry".


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

Re: [Imports-us] Importing new streets for Raleigh-Durham, NC

[Mike N]

On 5/7/2018 11:20 AM, Richard Welty wrote:

first step would be to verify license compatibility, you need a clear
statement from the
county that they permit publication under the ODbL (note that if data is
public domain,
or published under a CC0 license (effectively public domain), the answer
is yes.)



  Agreed - even better than checking for permission for ODBL usage, 
would be just to give explicit permission to bring into OSM, such as 
template #3: 
https://wiki.openstreetmap.org/wiki/Import/GettingPermission - that 
allows for a future OSM license change without having to re-obtain 
permission from the source.


   Then when coupled with a tasking manager or MapRoulette, this would 
make a great group project.  Assuming that the source data is open, 
tasks can be created just with the deltas and the new streets added as 
you were planning.   Once the license issues are addressed, let us know 
and we'll be glad to pitch in where needed.




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

Re: [Imports] [Talk-us] Microsoft Building Import for Greenville, SC

[Mike N]

There is some question about the overall accuracy of the height data in 
this import, but I think the units are correct in meters.  For example, 
the Landmark Building [1] is a known height of 305 feet / 92 meters. [2] 
Mapillary view (from a distance) [3] .


   Microsoft measured it at 101 meters / 331 feet; an error of 26 feet. 
 Since the building is on a slope, it's not known what reference was 
used as the base in the Microsoft height measurement.   A measure of 101 
feet would be 1/3 of the actual height and not what I would expect.


  Hopefully the units weren't mixed by using different units for 
different buildings.  I couldn't see any indication of this in the 
original shape file.


[1] https://www.openstreetmap.org/way/41979319#map=19/34.85453/-82.39767
[2] 
https://www.emporis.com/buildings/127342/landmark-building-greenville-sc-usa
[3] 
https://www.mapillary.com/app/?lat=34.855667=-82.39939=17=photo=lPCYDmX9ZV5E8JMd6xG3Kw


On 3/25/2018 2:54 PM, Leon Karcher wrote:

Hello Mike,

I think that you have made the same mistake as they made with the 
Tampa/Clearwater, FL Microsoft building data import: The height is given 
in feet and inches, but you used metre scheme (x.y) instead of x'y". An 
example:


This commercial building 
<https://www.openstreetmap.org/way/343235673> is never 16 meters tall as 
said in its height tag. (View on Mapillary 
<https://www.mapillary.com/app/?lat=34.829709115470564=-82.40749038763568=14.30535083537551=photo=ozDDkY97ETw_S7WwI9xZqQ>) 
If you compare further buildings, you will see that this is applicable 
for all others.


I hope you still can fix it, because the managers of the Florida import 
didn't.


Thanks,
Leon

2018-03-25 20:36 GMT+02:00 Mike N <nice...@att.net 
<mailto:nice...@att.net>>:


In accordance with Step 6 / item 4 of the imports checklist, the
import and QA is now completed.

Thanks to Microsoft for making building and height data available
and multiplying the efforts of a few local mappers!


    On 3/14/2018 10:21 PM, Mike N wrote:


FYI, this is proceeding with 2 people, on dedicated accounts
Greenville_SC_City_MSImport_1 and Greenville_SC_City_MSImport_2

    On 1/24/2018 8:28 PM, Mike N wrote:


The OSM Upstate SC group is planning an import of Microsoft
building shapes for the city of Greenville, SC.   The
candidate wiki page is at

https://wiki.openstreetmap.org/wiki/Greenville_SC_Building_Import
<https://wiki.openstreetmap.org/wiki/Greenville_SC_Building_Import>

    The actual import won't take place for 1-2 months yet to
allow time to review the plans.

    Mike



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



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





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

Re: [Imports] Worldwide fuel stations import, 59k objects

[Mike N]

On 3/8/2018 2:28 AM, Frederik Ramm wrote:

Paying brands will be
fully covered even in areas with no mapping activity, smaller
independent stations and non-paying brands will only be covered in areas
where a mapper happened to add them.


In my US state at least, the import will add no new stations, but adds / 
clarifies information on about 4 existing stations.   I'm suspecting 
this applies generally to the US where addresses have not been entered 
in OSM and there is no open geocoder.


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

[Imports] Microsoft Building Import for Greenville, SC

[Mike N]

The OSM Upstate SC group is planning an import of Microsoft building 
shapes for the city of Greenville, SC.   The candidate wiki page is at


https://wiki.openstreetmap.org/wiki/Greenville_SC_Building_Import

  The actual import won't take place for 1-2 months yet to allow time 
to review the plans.


  Mike

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

[Imports-us] Microsoft Building Import for Greenville, SC

[Mike N]

The OSM Upstate SC group is planning an import of Microsoft building 
shapes for the city of Greenville, SC.   The candidate wiki page is at


https://wiki.openstreetmap.org/wiki/Greenville_SC_Building_Import

  The actual import won't take place for 1-2 months yet to allow time 
to review the plans.


  Mike

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

Re: [Imports] Walmart import

[Mike N]

On 12/16/2017 8:01 AM, Ilya Zverev wrote:


OSM Conflator works only with nodes, except when it updates tags on
polygons. If you like mapping building outlines, please do a challenge
for MapRoulette after this import. Brandify doesn't have building outlines.


  A post-import MapRoulette challenge would make sense.  A natural 
progression when adding SuperCenter store detail is to add the POIs as 
separate nodes.   It should be no problem when adding them first except 
that the address would logically belong to the building unless the 
embedded stores have their own unit/suite number.




De-abbreviating street names and distinguishing "Fourth Street of Oaks"
from "4, Street of Oaks" is a very complex task, and unrelated to the
importing subject. I thought the street address from the source data
would be better added to some tag on an object, but without touching
addr:street and addr:housenumber. And addr:full looks good for this.
There is no rules for this tag, and city and country are usually
geocoded, so the value can help when searching.


  The nearby OpenStreetMap road name could help since it's already in 
the proper form.   But there are also many US or state Highways that 
haven't been set to a usable address name: for example the street and 
post office address would be "Highway 244" but the nearby US244 only has 
a ref but no name, or it is named "United States Highway 244".



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

Re: [Imports] Ottawa, Canada Tree Import

[Mike N]

On 6/28/2017 11:32 AM, James wrote:

Well that analysis is incorrect in itself as others have stated, OSM can
be wrong. So a river bank, building, etc may not be properly drawn. So
with that being said what you are saying is the only viable way to
accept an import is to manually review every single item in the dataset.



  Not all items in both OSM and the import datasets need to be manually 
reviewed.   Just review the conflicting items from an automated check to 
determine which one is correct.   It should be a small fraction of the 
items from both datasets.


  (+1 on this import)

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

Re: [Imports] Importing fuel stations in UK and future similar imports

[Mike N]

On 5/13/2017 6:27 AM, Andy Mabbett wrote:

On 13 May 2017 at 10:06, michael spreng  wrote:


private ones are a clear no like this navads_shell

A "clear no" in the sense that some of us think they're perfectly acceptable


 Acceptable, yes.   But having any value to OSM - no.  Consider the 
real life cases.


  1.  After the import, a mapper sees a new station just opened, so 
they add it to the map.   Without an id.
  2.   After the import, a mapper spots a closed station, so they 
delete the node or delete the information and mark it as disused.


  Database ids don't help resolving those common cases.

  So even with the best case of trying to apply a future import update 
by running a diff against the original import data, it is still 
necessary to run a conflation against OSM's data.



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

Re: [Imports-us] OVRDC Sidewalk Import

[Mike N]

On 11/15/2016 6:08 PM, Elliott Plack wrote:

After pressing "Shift-I", all of the new nodes are selected as well, so
you can add one of the point crossing tags. I don't know what the
consensus is on that tagging, but it is important that sidewalks and
roads intersect.


  One related additional detail: the intersection between sidewalk and 
railway is rail=crossing, instead of rail=level_crossing as it would be 
for a road.



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

Re: [Imports] Importing official Buildings/Addresses in Louisville KY

[Mike N]

On 1/31/2015 9:46 AM, Sander Deryckere wrote:

Updatability can be achieved by adding an id to the imported objects
(that id must be permanent in the source DB), but it's also possible
without id when you develop algorithms to compare OSM data with the
official data.


  An ID is not as useful as they might seem on first glance.   For the 
next round of import checking: there is a new ID which isn't in OSM. 
Was that building

  1.  ..Torn down and deleted from OSM?
  2.  ..Still present, but deleted by its owner looking for some sort 
of 'privacy'?

  3.  ..An erroneous extra building in the original database?

  There is also the case of newly created buildings in OSM and fully 
tagged by survey without an ID


  Object conflation ideally should occur on each import cycle.  Saving 
a copy of the original source data can help.   Then for the following 
import cycle, compare source data directly to get a direct list of 
changes from the source.



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

Re: [Imports] Import of addresses in Poland

[Mike N]

On 2/4/2014 2:52 PM, Frederik Ramm wrote:

I think it is probably not impossible to have a repository of ready-made
OSM files with house numbers for various areas, and anyone setting up
Nominatim could select the files for whatever areas they're interested
in.


I like this idea - it would be interesting if such a repository could 
have simpler licensing to serve as a place to collect and distribute 
publicly available address data.   I can easily track down public 
sources of address data for my region, but don't bother with the import 
process because of the equivalent hassle of getting 2 groups of lawyers 
to sit down and hammer out a license agreement for each import.



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

Re: [Imports] Import of addresses in Poland

[Mike N]

On 2/4/2014 3:27 PM, Dariusz Bączkowski wrote:

What about address visibility on OSM data generated maps/tiles?
Without does being visible on map no one can verify them.
Verification is way easier and anyone can do it in his city just walking
with map showings on his phone.


 There are many cases where addresses are not shown on OSM tiles.  For 
some examples:


  - Addresses spaced too close to render every one.
  - Addresses added as part of a single-purpose building such as a 
restaurant.   Therefore only the restaurant or building name is shown.


  A dedicated app or overlay that is aware of both OSM addresses and 
the hypothetical address repository would be better: show all addresses 
while walking down the street, and identify the source of the address by 
color.



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

Re: [Imports-us] Seattle Import

[Mike N]

On 12/14/2013 1:50 AM, Clifford Snow wrote:


Eric Fischer got me thinking when he was working on a tiger fix that we
need to retain this data for future updates, even if we don't know how
to do updates today. Rather than use kingcounty:id, shouldn't we have a
consistent method of identifying tags that may be needed in the future?
It's possible just using :id is sufficient. However, maybe something
like update:id, although that has problems as well.



Future updates must handle OSM mapper's edits:
  - A mapper adds a new building address to OSM before the next county 
update.  This must be detected and handled by the import re-sync 
conflation process without an ID.
  - A mapper removes a building address from OSM.  Re-import must 
answer the question of whether the building was torn down, or vandalism 
where the mapper wanted to decrease the visibility of a competing business.


I don't see the need for any database ID to link the data for future 
updates since it won't simplify that process.



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

Re: [Imports] NYC building + address import - to merge or not to merge?

[Mike N]

On 10/14/2013 12:35 PM, Alex Barth wrote:

## Option 2: Always keep address points separate


 I think this makes sense - I have gravitated in this direction with 
larger buildings; place a separate node (or reuse a building outline 
node) at the entrance most likely to be used by visitors; GPS navigation 
could use this to produce expected behavior.



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

Re: [Imports] Add to discard ist : more tiger tags

[Mike N]

On 9/12/2013 3:17 PM, Bryce Nesbitt wrote:

The tiger:zip_left_XXX series however... does not have a purpose I can
fathom.



  It's supposed to be useful when the zip code differs from one side of 
the road to the other.   It gets crazy when used on winding roads.


  I personally find tiger:county to be useful when landing somewhere 
random from a note or link and want to do more research against current 
TIGER data for that county.  There are probably other tools for that, 
but I haven't had to track them down yet.



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

Re: [Imports] TIGER realignment import

[Mike N]

From 45045-.osc ,

Node 112700339
Node 112685698

are parts of Interstate highway.   The nodes were nudged from their 
original position, and the result is a jog (or slightly sharper angle) 
in the main interstate line of travel.   In my opinion, 100% of 
interstate highways have already been manually reviewed and could be 
excluded from the realignment.   What do others think?



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

Re: [Imports] TIGER realignment import

[Mike N]

On 8/7/2013 1:54 PM, Bryce Nesbitt wrote:

Ok, well how about with non-bot edit ways excluded?  If a hand mapper
touched a way, exclude it.


  I have traveled through several TIGER deserts and performed alignment 
based on my GPS tracks.   I aligned side roads at the intersections, but 
did not continue aligning the side roads to their endpoints because I 
did not have a GPS track for reference; often the road disappears under 
trees, and at times the TIGER way for a main road went down a side road 
by accident.   Without a GPS track it was hard to know for sure.   Many 
of those now have very accurate TIGER data now.


   In summary, in my opinion, I would rather have all the new 
alignments in the .OSC and manually review them all - they often point 
to something else that needs to be corrected anyway.


  I haven't found any major problems with the points I've looked at; 
I'll know more when there is an easy way to review the effects of each 
proposed alignment change.



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

Re: [Imports] TIGER realignment import

[Mike N]

This is a fantastic tool, and will be a great timesaver!

On 8/6/2013 7:11 AM, Serge Wroclawski wrote:

But even looking at a county in NJ, it's hard to do any serious
review, because if you open an osc file in josm, you'll want to look
at the parent objects too, and when I tried that (File-Download
parent ways/relations), it ran for 15 minutes, and then I stopped it.
That was one of the smaller osc files...


  Is there any way to use a daily .OSM file in JOSM to do this review?

  To date, I have been importing new TIGER subdivisions by copying them 
from another JOSM layer.  I would say that the majority need to be 
reviewed against Bing before uploading to resolve connectivity and 
improve alignment, or to add turning circles while reviewing.



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

Re: [Imports] Fwd: Re: Spanish cadastre

[Mike N]

On 3/28/2012 9:06 AM, Iván Sánchez Ortega wrote:

Also, guess how many Spaniards have spoken against this import.


 I'm not trying to be sarcastic, but I'm curious if any locals have 
spoken against the import.   Also if anyone has mapped when visiting 
other areas with the Corrine or LandUse imports and been happy with the 
edit experience?


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

Re: [Imports] Spanish cadastre

[Mike N]

On 3/23/2012 7:10 AM, Ander Pijoan wrote:

This have been discused and my personal point of view is that this
metadata, joined with all the other data already provide in the databas,
make possible to do interesting research in the enviormental area.


After parcels have been imported, are they improved or corrected in any 
way?   If not, researchers can easily combine cadastre data with OSM 
data in their own database to perform studies.   That way they will 
always be using the latest cadastre data as well.


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

Re: [Imports] Bus data for Fairfax Connector, Fairfax County, Virginia, USA

[Mike N]

On 8/28/2011 4:53 PM, Stefan de Konink wrote:

Will not work, because in order for Google to accept those, it should be
validated and have the origin of the operator...


  However, GTFS schedule data is still useful for online routing using 
OpenTripPlanner for example.   There could be other OSM+GTFS routing 
solutions in the future.


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

Re: [Imports] import of data - which account to use?

[Mike N]

On 6/23/2011 6:49 PM, Robin Paulson wrote:

i have seen two suggestions of which import to use when importing data
- personal accounts belonging to the mappers doing the import, and an
acount created specifically for the import. which is preferable, and
why?


  The preferred approach is definitely a separate account for that 
import.  There are other ways to identify the import, even if a separate 
account is not used, but such solutions take more time from those who 
might need to inspect / change something directly related to the import.


  If you don't already have and regularly check multiple email 
addresses, this can be a challenge.   With GMail, there is a way to 
create an alias for the import account, but a message from anyone trying 
to contact you will show up in the inbox:


http://mail.google.com/support/bin/answer.py?answer=12096



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

Re: [Imports] Fwd: [OpenStreetMap] Uploading filling stations

[Mike N]

On 5/19/2011 7:58 AM, Josh Doe wrote:

  I've yet to have
any interest in the plugin, so if anyone sees value in it let me know.


Just for the record, I have great interest in this plugin, but have been 
consumed with my day job.   This has the potential to create quality 
reviewed imports as they are brought in, rather than dumping them in OSM 
for others to fix the duplicates.


I would like to be able to extend for use in fixing roads with newer 
data as well.


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

Re: [Imports] readonly tag for imported data (ask simple editors to not modify)?

[Mike N]

On 4/26/2011 11:39 PM, Anthony wrote:

Not sure what you mean.  Why can't you just use the way id, and keep
the way id-  TLID table offline?  (Yes, the mapping will get messed
up as people split and delete and recreate ways, but that's what's
happening with the TLIDs anyway.)


  That certainly *could* be done, but the OSM database was just a 
convenient way to store it at the time of import.   It can be deleted 
later or at any time we feel it has lost usefulness.   I don't think 
we're quite there yet.



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

Re: [Imports] How good can an import be?

[Mike N]

On 4/6/2011 8:15 AM, Hillsman, Edward wrote:

There are many good-sized cities in the US with very few edits. I'm tempted to propose an 
experiment. What if we (figuratively: I mean the OSM Foundation or an 
authorized group) simply removed all of the original-and-unedited imported TIGER data 
from a few of these. Leave everything else in place. Then do some outreach/publicity in 
these cities and a few others of comparable size, situation, and mapping activity, and 
then observe the subsequent mapping rates.


 A good time to do this is in conjunction with the ODBL conversion - 
when we remove the edits of those who can no longer be contacted or who 
do not agree to the new terms.   That way the consumers such as 
navigation apps, etc will already be prepared for the loss of usable 
navigation.   Even in Bad TIGER cities, the interstate highway system 
is often in good condition.It would also be good to choose a city 
with poor TIGER road alignment to remove the unedited data.


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

Re: [Imports] How good can an import be?

[Mike N]

On 4/6/2011 8:21 AM, Anthony wrote:

importing TLIDs was a huge mistake, for starters


 Why was it a huge mistake?   If it proves not to be useful for future 
reference, it can be ignored and later deleted.   I can see problems 
with it, and can't see how to make any use of it, but wouldn't call it a 
huge mistake.


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

Re: [Imports] Importing Arkansas data

[Mike N]

On 3/28/2011 3:13 PM, Ian Dees wrote:

before continuing dumping this data into OSM?


 I see that this previous question has not been answered -

 Do you reupload the whole changeset (thus duplicating data)?

   The answer right now is yes.  (3/24 2, 3/25 2)

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

Re: [Imports] Import of Belize roads

[Mike N]

On 3/2/2011 1:33 PM, Lars Kotthoff wrote:

Is there any way of doing this and preserving the attributes?


  Also take a look at Shp-to-OSM: https://github.com/iandees/shp-to-osm 
.  It supports a flexible tag mapping method.   The only trick I ran 
into is cases where I needed to map a single attribute to multi 
attribute: for example, alleys (highway=service, service=alley).  I just 
made up a temporary mapping that I could later edit in JOSM.



I also had a look at the cloudmade dump for Belize and a large number of nodes
are connected to a node several thousand km away from whereever it should be.


  I loaded the cloudmade Belize extract, and I don't see the phantom 
connections when I load it in JOSM.   I do see large numbers of empty 
nodes - the cloudmade extract is missing much coastline.   Could you 
post one of the node ID numbers?



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

Re: [Imports] Import of Belize roads

[Mike N]

Would it be acceptable to import this data set? Is there any way I could overlay
it with the existing data to see which roads are there already? I'm aware of the
usual tools like JOSM, but they only allow me to get the data for a small area
and I don't want to download planet.osm just for that.


 If you feel that the PD dataset is of sufficient quality, that should 
be fine.   Cloudmade has a pre-built country extract for Belize that 
looks to be small enough to conveniently load into JOSM:


http://downloads.cloudmade.com/north_america/belize#downloads_breadcrumbs


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

Re: [Imports] [Talk-us] Importing Virginia road centerlines

[Mike N]

I'm totally new to importing, so I first wanted to see if anyone else
is interested in this project, though I am willing to take the time to
learn the process myself. Is the process used for importing the
Canadian database [1] the best method for doing this?


  The process for the Canadian database is best used only for adding 
new roads that don't exist in the OSM database.  As part of the upload 
process, plan on stitching them into existing roads, perhaps using JOSM.


  It would also be handy to be able to project the improved geometry 
onto existing roads of the same name, while preserving attributes and 
driveway / footpath / bridges that have already been added to the OSM 
data.That will preserve user's contributions and history.  This 
would require some new, yet-to-be developed tool to work directly with 
OSM data.  There is much interest in this because of the TIGER 2010 data 
and Arkansas state data sets.   It is not certain when there will be 
developer resources to develop such a tool.


  The limitation of Roadmatcher is that it works only with shapefiles, 
thus OSM attributes are lost when exporting to shapefiles.


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

Re: [Imports] US Forest Service Data

[Mike N]

On 2/3/2011 9:17 PM, Tom Ponte wrote:

But before I get too far along with that is there any talk of updating
these roads with newer data like the newer tiger data –(for all forest
service districts)? I haven’t looked into how much of that there is in
the areas managed by the FS to see it is available or if it is any
better – as good as etc. I sort of doubt it is better or as good unless
it is now derived from FS data somehow.


  I believe that having the best data is the way to go - in this case 
if you can verify that centerlines are accurate, current and have names, 
it is unlikely that the latest TIGER would be better, so a replace and 
connect to border roads operation would seem to be a good plan.



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

Re: [Imports] Arkansas address point import

[Mike N]

On 1/25/2011 12:14 PM, Nathan Mills wrote:

I propose to import the situs address points available from Geostor


   In considering future synchronization cycles with point data, 
several cases can be seen:


 A.  Mapper deletes an address node.
 B.  Mapper moves an address node.
 C.  Mapper creates a new address node.
 D.  GeoStor data deletes an address node
 E.  GeoStor data moves an address node
 F.  GeoStor data creates an address node
 G.  A street is renamed

  For case A, you would not want to have the address node pop up again 
from a future update.

  For case B, you would not want to re-place a node in the old location.
  For case C, you would not want to place a duplicate address node from 
GeoStor

  Case D should result in removal of the address from OSM
  Case E should relocate the node in OSM.
  Case F should upload the new node.

 So how can this be accomplished?   For case A, you have a node that 
isn't found in OSM's database, so it should be uploaded, but there is no 
way to know that the node was actually deleted.  To handle this, the 
previously uploaded dataset can be used to determine a delta.


 Future update cycles might be -

  Create Geostor delta consisting of adds, deletes, and moves since the 
previous upload.
	Adds which are not a duplicate of existing OSM (houseNumber+StreetName) 
will be uploaded.
	Deletes will be removed from OSM if found.  A question is whether to 
also automatically delete mapper-created addresses by matching 
houseNumber+streetName

Moved nodes will be relocated if the original node has not been moved.

  The street rename case just involves updating changed information for 
the matching OSM (houseNumber+streetName) node, which might have been 
originally created by Geostor or a mapper.


  The Geostor object ID could be useful for matching objects between 
the databases.


   It would seem that it is useful to retain the last uploaded dataset 
somewhere.  Does Geostor retain an archive of all previous versions of 
datasets?



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

Re: [Imports] Arkansas address point import

[Mike N]

On 1/25/2011 12:14 PM, Nathan Mills wrote:

I propose to import the situs address points available from Geostor


  I'd recommend creating a page on the Wiki for this import - link to 
it from the base Arkansas page 
http://wiki.openstreetmap.org/wiki/Arkansas ; new local mappers should 
arrive here to learn about past and future mapping projects.


  It's handy to use a dedicated OSM account for import - this can help 
with troubleshooting or syncing future imports.



(http://www.geostor.arkansas.gov/G6/Home.html?q=situs+address). I have
confirmed with that this data is public domain, and spot checks of its
accuracy in areas I'm personally familiar with show that the vast
majority of the points are of high accuracy.


  The address points will be more accurate than many of the roads. 
This could result in confusion for beginners when roads drift through a 
line of address points, but they should be able to see from aerial 
imagery that the road needs to be realigned.   And there will be an 
ongoing effort to update and align the roads based on either TIGER 2010 
or the Arksanas geo clearinghouse.



I'm open to suggestions as to how to better tag the points if anyone has
any ideas.


  I spot checked in one location, and I'd say it is tagged correctly. 
 One point for discussion:


   source= for each data point.   One might argue that the source= is 
only required on the changeset comment.   This avoids the confusion  of 
someone correcting an address point but not updating the source= tag. 
That also saves space in the database.   The changeset comment can 
contain a link to the import page.


  I see that the addr:street names have been un-abbreviated, so that 
they should match the new roads when they are updated.





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

Re: [Imports] Arkansas address point import

[Mike N]

I could do a mass import of the roads from the Arkansas Centerline File,
which is also public domain. ;) (I'm not serious, that would be a
nightmare)


   There is serious talk of developing one or more tools to automate as 
much of the updating process as possible.  It won't be as simple as a 
mass upload, but much easier than straightening all of them out by hand 
and checking for updated names.


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

Re: [Imports] [Talk-us] Arkansas address point import

[Mike N]

On 1/25/2011 8:44 PM, Josh Doe wrote:

I would definitely be interested in these tools. Fairfax County, VA, USA
has very good centerline data, including speed limits and route numbers.
They also regularly release updates. Is there something on the wiki or
ml about planning for these tools?


  The only discussion so far has been on the ml  - 
http://lists.openstreetmap.org/pipermail/imports/2010-December/000723.html 
.  There is not yet a concrete project - it could take several forms 
depending on who implements it: a JOSM add-on and/or bolting onto 
another editor or tool.


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

Re: [Imports] Import US County data

[Mike N.]

FYI - I have an import for Murray County, Oklahoma, US nearly ready - at step 
11 and will probably happen within the next week -

Wiki page: http://wiki.openstreetmap.org/wiki/Oklahoma/Import/Murray

 Peruse the proposed dataset in JOSM at:
http://greenvilleopenmap.info/roads5.zip
   Please Do not try to upload - the upload will fail in the current data 
state, and result in a messy possible partial upload 

For a quick summary, here is an overlay of the 2 datasets, with some of the 
proposed data selected in red to stand out against the street in the aerial 
imagery.  http://greenvilleopenmap.info/StreetCompare.jpg

 The aerial imagery for this region is likely to be within 2M of actual, as 
confirmed by downloading GPS traces taken on I35.   The county GIS data 
centerline accuracy appears to be very good and much better than the original 
TIGER data.

   o  Data is public domain, per the contact in the county's GIS department

   o  An analysis shows that the only edits in the county have been to the 
Interstate (Relation / Dual Carriageway / Align/ Exits / ref), the Turnpike, 
and US Highways (relations / refs).

Notes:
  1.  The data itself will have no source= attribute, just as the dataset 
roads5.osm currently exists. The attribution will be on the changeset itself 
with the source= pointing to 
the OSM wiki import page entry. 
  2.   There is no attempt to maintain a link back to the original county  GIS 
shapefile dataset elements - future edits will be smaller in scope, and will 
likely come from diff files, TIGER, or local mappers via aerial imagery or GPS 
traces.
  3.   The address data from the county's dataset will not be imported because 
I have no way to verify its accuracy level.   It would probably be better than 
TIGER's anonymized address interpolations ranges, but would only be address 
ranges on a street, and may not correspond 100% to physical address locations.

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

[Imports] Import US County data

[Mike N.]

I have obtained a set of road centerlines from a US county that has been 
published in the public domain.   I would like to use this to correct the 
OSM roads for that county, since the TIGER data was one of the poor 
alignments that we are so familiar with.   In addition, the road names have 
all been changed for E911 consistency.   This file is likely even newer than 
the 2010 TIGER centerlines.


 I have used Ian's shp-to-osm to begin looking at the data.

  1.   Does anyone have a rules file for a typical municipal road 
centerlines shape file conversion? I started to develop this, but can't 
believe no one has done this before.
  2.   Is it good to preserve TIGER tags for untouched roadways, or just 
delete and replace them?   The geometry is so far off that it is easier to 
delete and replace.


 Usual import disclaimers -

 Any relations will be preserved.
 Any existing road alignment edits will be preserved (such as for 
interstates)
 Any existing attribution will be preserved (speed limits, traffic lights, 
etc)
 Corrected data will be manually stitched to existing data at borders or 
pre-edited roads.




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

Re: [Imports] MapQuest translation of Beijing - requesting feedback

[Mike N.]

4) Download the osm data again to get latest set
5) Reform the osm data file with the new translated fields by inserting 
xml
tags for the native and english language attribute for nodes/ways, 
matching

by ID
 a) Would check first that the Version is the same before updating
 b) Ones with different Versions would be retrieved for manual
inspection/resolution


Not sure I understand this correctly. If you do (4) then you have the 
latest data set and you will apply your change to that. Then 5(a) makes no 
sense (what version would you compare against?). Instead, just upload the 
stuff and if one of the objects should have changed in between (4) and (6) 
the API will give you an error message.


 5a could be a check if the value of nameNative changed during the 
translation cycle.   That would mean that the translation may be invalid - 
and those entries would be discarded or reviewed.




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

Re: [Imports] MapQuest translation of Beijing - requesting feedback

[Mike N.]

So, go ahead, make your list of changes locally, then, provide .osm
files, split into small regions and ask the community for help to
merge.

 Time consuming, yes, quality?  OSM prefers to build a
community map, over a quality map. A quality gets better, only over
time and more mappers.


  Perhaps I missed something, but I thought the proposal was sound and fits 
within the framework and spirit of OSM.   I don't understand the need for 
community to merge - there is no geo-merge involved, it's just a newer 
version of the same object.   That lends itself well to a computerized task.


  There's always the question of the impact of a large temporary labor pool 
on community, but this is no different than any other import.I see this 
as a 'high quality import' because it accomplishes exactly what is 
intended - no dirty post import review or clean up.


  Re: complaints of not using the OSM tools - again I have no problem with 
this.  Essentially, their workflow represents a customized OSM tool, 
optimized to present the translator with just the information they need to 
do their job efficiently.




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

Re: [Imports] [Talk-us] [US] NHD04090004

[Mike N.]

One thing I see is that this river shows at the edge of the NHD export 
boundary.   I have seen cases where an NHD feature does not appear in the 
NHD export sub-basin that one would expect, but in the adjoining NHD 
sub-basin export.   Some times the same feature - usually a river - appears 
in  multiple sub-basin exports.  I have no idea about this specific case.

--
From: Nakor nakor@gmail.com
Sent: Monday, March 15, 2010 9:25 PM
To: Talk-us U.S. talk...@openstreetmap.org; imports@openstreetmap.org
Subject: [Talk-us] [US] NHD04090004

Hello,

 I was importing NHD data in my area and found some issues in the data I
 downloaded: The Rouge River in Detroit area
 (http://maps.google.com/?ll=42.450077,-83.303661z=16) is visible on
 the NHD map (see attached screenshot) but is missing from the dataset I
 downloaded and uploaded to OSM (see
 http://www.openstreetmap.org/?lat=42.450077lon=-83.303661zoom=16).
 Have anybody ever seen this kind of issue? Any clue on how to get that 
 data?
 


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

Re: [Imports] [Talk-us] Import of Lakes from water.usgs.gov

[Mike N.]

 There is a HUGE amount of data to import from the government, if
 anyone is interested we can continue!
 here are some of the types of data in that  file:

 grep -i landuse  g36090.osm  | sort -u

tag k=LANDUSE v=Commercial and Services/

  Hi James,

  I would prefer not to have LandUse for my region at this time, mainly 
because editors do not yet support ignoring objects - the boundaries 
interfere with correcting roads and adding landmarks - at times edits are 
excruciating. Be sure that people in the affected areas want the data 
imported and that there is no better source available first.

   NHD data is useful and generally does not interfere with road and 
landmark correction and updates.   Sign up for your areas of interest on the 
Wiki to avoid duplicate imports.

http://wiki.openstreetmap.org/wiki/NHD


 (PS I think the JOSM editor team is working on a mask / layer / ignore type 
feature to address the data overlap problem in the future)
 


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

Re: [Imports] NHD import process

[Mike N.]

 I get OSM files but the issues is that several entities have no names.
 How can I get them?

  In a few cases, the name is assigned to the relation instead of the water 
body.  For all other un-named entities, it would be like un-named ways - 
verify them by on site survey; occasionally the water body name will be 
posted on a bridge.   If the entity is large enough, it may appear in 
Wikipedia.Beyond that, it is very difficult - you would need to rely on 
local knowledge, etc.

 The line file is empty. What is it supposed to contain?

  In some areas it will be empty.   In other areas it commonly contains 
dams.

 Are all of these useful and should all of these be uploaded?

  Everything in these files is thought to be useful and should be uploaded. 
Any filtering takes place in the scripts.

 Finally how can I merge various OSM files? I tried from JOSM but it
 takes forever.

  I've not found a good solution to this, other than JOSM on a 'horse of a 
machine', but it's still slow.   I usually spot validate several files 
against local knowledge or aerial shots, then upload them with 
http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/bulk_upload.py
 . 


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

Re: [Imports] [Talk-us] HI: Hawaii GIS Data

[Mike N.]

Why oh why oh why do some people insist on wasting time trying to import loads 
of data?

   I like to view OSM data as capable of creating some usable map types on its 
own, rather than just a possible supplemental feed to Google maps in the 
future.  As such, landmarks are key to a standalone map:

A map without streams and rivers is not real to me.   That's where the NHD 
import comes in.   After the import, I frequently update the actual hydrography 
features for changes caused by new construction.   Not a waste of time to me, 
and the map is useless without those hydro landmarks.   I certainly wouldn't be 
slogging up thousands of streams and rivers - most of which are on private 
property  - trying to map any of them myself.

   Similarly, larger park boundaries could not be reasonably mapped without 
special arrangements from park management to stray off marked trails and file 
your survey plan.   Most parks would not allow casual access off their marked 
trails for good reasons.So parks are another useful landmark import.

  Trails - if accurate, why not use them?  The end result is a good start so a 
later mapper can spend time adding trail landmarks and details rather than the 
trail itself.

   Aside from that, I'll agree that importing just because some data is 
available is not good, and firsthand survey data is much more valuable.   After 
all, if someone wants to make their own voting district map (which can change 
every year), they just combine the public voting district data with the OSM 
features they need at that time.

 - Mike

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

[Imports] NHD Duplicate data

[Mike N.]

Doing a routine pre-upload checklist, I found a case where there was a large
section of duplicate river overlap in adjacent NHD water basin extracts.
This was the Mackinaw river in sub-basins 07130003 and 07130004 .This
becomes easier to see by loading the entire upload into JOSM - the
'flowlines' create a scatter plot that roughly follows the borderline on the
NHD download map.   But duplicates extend for a long distance outside the
primary sub-basin boundaries as indicated by the flowlines.

   I'm not sure what the best solution is; a program to detect duplicate
areas may not detect duplicates from an adjacent upload by a different
person.

 


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