Re: [Imports] Bing Building Import

[Elliott Plack]

IMO building imports with community mapper buy-in increase involvement by
removing mapping tedium and highlighting other problems like missing roads
without needed to pore over imagery.

MS has a thorough third-party notice for the tool used to create the
buildings:
https://github.com/Microsoft/CNTK/blob/master/ThirdPartyNotices.md via
https://blogs.bing.com/maps/2018-06/microsoft-releases-125-million-building-footprints-in-the-us-as-open-data/


On Tue, Jul 3, 2018 at 5:56 AM Frederik Ramm  wrote:

> Hi,
>
> On 03.07.2018 11:37, Christoph Hormann wrote:
> > 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.
>
> Unless, of course, the data is not simply shoved into OSM state by
> state, but split up into user reviewable chunks so that human mappers
> can review and upload the import for their region.
>
> Large imports are often detrimental to community building, but if you
> resist the temptation of simply having one guy run the import for a
> whole state, and instead say "hey, Arizona is mostly done but we're
> still looking for someone from counties X, Y, and Z to run the import
> there", you *might* even manage to get some people "take ownership" who
> otherwise would only have watched from the side.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___________
> Imports mailing list
> Imports@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-- 
Elliott Plack
http://elliottplack.me
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Facebook's AI-Assisted Road Tracing for OSM

[Elliott Plack]

Lots of negativity here. I'm all for this import. I like the fact a major
American tech company is willing to pour resources into an open source
project. All this data benefits FB but rather than hoarding it in their own
map, they're opting to put it on OSM.
On Thu, Mar 16, 2017 at 07:38 Christoph Hormann  wrote:

> On Thursday 16 March 2017, James wrote:
> >
> > Seeing as facebooks computational power will rival that of super
> > computers, even if you wanted to recreate it, it would probably take
> > you 1000 years of home computing power to "train" the neural network
> > to recognise roads, at which point we will all be dead.
>
> That is not how this works although i understand how PR of Facebook and
> others makes people believe that.
>
> You can perfectly use neural networks and other 'artificial
> intelligence' techniques on hardware accessible to normal people.  The
> difficulty with getting useful results with such techniques is not the
> computing power required (this hardly ever is the case for anything
> these days), it lies in adjusting such a system for the task at hand
> and training it to produce useful results.  In contrast to an
> intelligent human who validates his/her conclusions with a large amount
> of life experience an artificial intelligence will happily produce any
> kind of nonsense if it is set up to do so - either voluntarily or
> accidently because of lack of expertise in using these techniques.
>
> Which is exactly why we need to evaluate the results in full before an
> import in OSM and not just a small sample area.
>
> This is also a kind of chicken-and-egg problem - people use 'artificial
> intelligence' techniques because they don't want to bother with
> analyzing and understanding the underlying mechanisms of a problem they
> are trying to solve so they say "let's just have the AI figure it out".
> However to really properly set up and train the AI they actually need a
> thorough understanding of the underlying mechanisms.
>
> If Facebook does not want to open their methodology for whatever reason
> that is perfectly fine but if they want to import their results in OSM
> they need to either open their process or open the data as a whole for
> us to evaluate before the import - as i already explained in my initial
> reply.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Imports mailing list
> Imports@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-- 
Elliott Plack
http://elliottplack.me
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] [Talk-us] Potential data source: New York City watershed recreation lands

[Elliott Plack]

ing is as follows:
>  leisure=nature_reserve
>  For the benefit of legacy renderers that do not yet comprehend
>  the details of boundary=protected_area
>  boundary=protected_area
>  protect_class=12
>  protection_object=water
>  Tailor-made for this data set!
>  operator='New York City, Department of Environmental Protection,
>Bureau of Water Supply'
>  website=http://www.nyc.gov/html/dep/html/recreation/index.shtml
>  name=(obtained from the 'unit' column of the list of sites, with
>  the word, 'Unit' postpended)
>  access=yes (if the 'PAA' column is 'Y') or access=license (if the
>  PAA column is 'N')
> access:license=
> http://www.nyc.gov/html/dep/html/watershed_protection/recreation.shtml
>  if (access=license)
>  access:hiking=(value of the 'hike' column, normalized to 'yes' or
> 'no')
>  access:fishing=(value of the 'hike' column, normalized to 'yes' or
> 'no')
>  access:hunting=(value of the 'hike' column, normalized to 'yes' or
> 'no')
>  access:trapping=(value of the 'trap' column, normalized to 'yes'
>  or 'no')
>  nycdep:version=MMDDHHMMSS
>  UTC time returned as Date-Modified from the web site. See
>  below for rationale of retaining this information.
>
> I'm more than open to a different tagging scheme for 'access'. What
> the relevant restrictions are:
>
> PAA=Y areas are open to all comers, no permission needed, for the
> activities specitied. PAA=N areas require a free access permit
> obtainable at the web site
> http://www.nyc.gov/html/dep/html/watershed_protection/recreation.shtml
>
> HIKE, FISH, HUNT, and TRAP describe the permitted activities (HIKE
> encompasses related activities such as photography, bird watching,
> etc.)
>
> The areas in which HIKE=N are all areas adjoining the
> reservoirs. Hiking with no other purpose is forbidden in these areas,
> as is the trapping of game. Hunters, fishermen and boaters accessing
> these areas must have valid licenses for these activities, and boats
> must be tagged by NYCDEP. Since all of the HIKE=N areas are also
> PAA=N, lawful users will have applied for an access permit and been
> presented with the restrictions, so I don't propose to model this
> complexity in the tagging, unless someone suggests a more obvious
> tagging scheme than I've been able to invent.
>
> CONFLATION AND UPDATE PLAN
>
> The initial conflation should be quite straightforward - simply query
> a PostGIS mirror for area features that overlap the supplied
> multipolygons by more than a trivial amount. (The cadastral data from
> the different agencies are not 100% consistent, so I expect that a few
> per cent of some parcels will overlap adjacent state forests, and
> intend to import these data as is. Rectifying misdrawn property lines
> is not our problem!) I propose simply to import the parcels into JOSM,
> resolve any JOSM-reported errors and warnings, and upload. I will
> likely work either by county or by township, depending on the number
> of parcels in a county, to keep each upload to a manageable size.
>
> Further updates in semi-automatic fashion should also be fairly
> straightforward. I propose to maintain a record of what has been
> uploaded, and when changes appear, check whether the OSM data for a
> parcel have changed from the previous upload. For unchanged parcels,
> the old can be replaced with the new withough stepping on any mapper's
> manual work, For new parcels, the upload can proceed. For changed
> parcels, the change has to be alerted for manual review. I expect that
> this last situation will be vanishingly rare. Of course, if the new
> upload results in a conflict (e.g., a substantial overlap with an area
> feature already in the database), the change will have to be flagged
> for manual review.
>
> FURTHER NOTES
>
> I'd much rather work from the bureau's own shapefiles, of course, but
> I've not yet managed to locate an appropriate contact to request
> them. Filing a demand under the Freedom of Information Law is often
> regarded as a hostile act, and I'd rather stay on good terms with the
> officials involved, so I prefer to proceed by less formal means. The
> 'web scraping' outlined above at least works, although I expect that
> it will be a brittle process in the long run. I'll keep casting about
> for a more robust way to handle this data set.
>
> NEXT STEPS
>
> Of course, I'll make source code of all scripts available for review
> and so that I can pass the baton for others to carry out the
> semiautomated update process if needed.
>
> If this proposal doesn't get roundly shot down, the next steps will be
> to create a project page on the wiki, link it to Import/Catalogue,
> clean up and publish the scripts, perform the import onto the test
> server, get a data review, and then update the Contributors page and
> do the import for real.
>
> Comments?
>
> --
> 73 de ke9tv/2, Kevin
>
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
-- 
Elliott Plack
http://elliottplack.me
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] [Talk-us] Dakota County Mn Bulk Building and Address Import

[Elliott Plack]

Joe,

I agree with Greg that this is a great start. Let us know if you need help
with the import merge workflow, as you have that as TBD on the wiki. In one
import I used an ArcGIS workflow to detect and set aside conflicts, and in
another we used a PostGIS workflow. Chunking the data up by district or
neighborhood is a great way to spread out the work.

For existing buildings, I'd typically leave them in place (unless the
geometry was really poor in which case I'd remove them) and just import an
address point (assuming that info was missing from the existing building,
as it usually is). Then, if you want, you can conflate the address points.

To Frederik's points, I definitely agree that adding source tags to the
buildings is no longer a best practice. Changeset tags are the way to go,
especially now that people can comment on your changesets. I suggest that
you add the website=* tag on your changeset and link to the wiki, e.g.
http://www.openstreetmap.org/changeset/24847251#map=12/39.4017/-76.6022

Kindly,

Elliott


On Thu, Apr 7, 2016 at 12:04 AM Greg Morgan  wrote:

> On Wed, Apr 6, 2016 at 10:17 AM, Joe Sapletal 
> wrote:
>
>>
>>
>> I’m looking for some assistance and support for doing a Bulk Import of
>> buildings with address information.  I’ve already assembled the data from
>> the source, but I need help converting it and uploading it and to build
>> community support.  I started a wiki page here -
>> http://wiki.openstreetmap.org/wiki/Minnesota/DakotaCounty/Buildings_Import
>> it links to a couple of samples areas of the data.  One I’ve already
>> uploaded as a test at this location -
>> https://www.openstreetmap.org/#map=17/44.74096/-93.10751
>>
>>
>>
>> Any assistance would be great.
>>
>>
>>
>>
>>
> Joe,
>
> That is some beautiful work.  I like how you are limiting your work to a
> small area.  How are you going to grow otherwise?  I like how you are just
> working on an area that you have edited.  That respects other mapper's
> work.  One change that you should consider is how to merge these foot
> prints with other mapper's work.  For example, I looked at one building.[1]
> This is your own work.  However, I'd find a way to preserve the existing
> way and nodes so that you change the features in place.  It builds on other
> mapper's work.  I also included a link to whodidit for your area.[2]  I
> have whodidit zoomed in but the map may take a bit to load.  What you are
> looking for are mappers in your area that may want to take part in the
> effort.  Whodidit is just one example and one way to find this information.
>   You may find that there are no mappers in your area that have an interest
> in this effort. If that is the case, then there are other mappers in the US
> that would like to see you succeed in a positive way.  They may be willing
> to pitch in as part of a community effort as long as you have diced up the
> data for multiple mappers to participate.  I think you should start with
> the US mailing list for guidance.. I believe mappers on this list would be
> more helpful than on other lists. As you refine your process and get good
> feedback, then you can move to other lists for the final import plans.
>
> I hope this helps get you started,
> Greg Morgan
>
> [1] http://www.openstreetmap.org/way/396603853/history
>
> http://zverik.osm.rambler.ru/whodidit/?zoom=16&lat=44.74246&lon=-93.10183&layers=BTT&age=1000
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
-- 
Elliott Plack
http://elliottplack.me
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] bicycle parking in Madrid manual import

[Elliott Plack]

Great documentation on the wiki! Good luck with the process. I hope it will
be useful for folks to find bike parking.
On Sun, Apr 3, 2016 at 18:47 Santiago Crespo 
wrote:

> Hi Imports,
>
> I'm planning to manually import some 1,185 bicycle parkings in Madrid.
> The data comes from the City Council of Madrid open data site:
> datos.madrid.es
>
> Check the wiki for the details:
>
> https://wiki.openstreetmap.org/wiki/Madrid_Bicycle_Parking_Import
>
> Discussed on talk-es mailing list and no objection were made.
>
> Because the source for each node and for each photo could be various
> departments and organizations, we have to respect that and use the
> source=* for each node.
>
> You may review the data (not reviewed yet) here:
>
> http://flanera.net/aparcabicis_por_revisar.osm
>
> Already reviewed the first chunk of 50 nodes and the data seems good.
>
> BTW, this is my first import.
>
> Thank you,
> Santiago Crespo
>
> ___
> Imports mailing list
> Imports@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-- 
Elliott Plack
http://elliottplack.me
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

[Imports] Proposal to replace inaccurate Everglades Agricultural Area data

[Elliott Plack]

Greetings,

I am proposing a small import to replace some inaccurate and imprecise
protected area boundaries in Florida with some public data obtained from a
government body.

The import covers one feature in Florida, USA: the Everglades Agricultural
Area. The data currently in OSM is neither accurate nor precise, using a
landuse tag to cover what is a government boundary, and does not give a
source. The current data was added by NE2 in 2012.

The proposal would remove the current data and replace it with the public
data under the protected_area tagging schema.

The full proposal document is available on the wiki for review, with links
to the data and other requisite items.

http://wiki.openstreetmap.org/wiki/Florida/Everglades_Agricultural_Area

Let me know if you have any feedback.

Thanks,

Elliott


-- 
Elliott Plack
http://elliottplack.me
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Need advice: Import wheelchair accessible places?

[Elliott Plack]

gt; Chairman / Vorstand
>>>
>>> Web: http://www.sozialhelden.de
>>>
>>> SOZIALHELDEN @ facebook <http://www.facebook.com/sozialhelden> - twitter
>>> <http://www.twitter.com/sozialhelden> - flickr
>>> <http://www.flickr.com/photos/sozialhelden> - YouTube
>>> <http://www.youtube.com/sozialhelden> - betterplace.org
>>> <http://de.betterplace.org/organisations/sozialhelden_ev>
>>>
>>> *Spendenkonto:*
>>> SOZIALHELDEN e.V.
>>> GLS Gemeinschaftsbank eG
>>> IBAN-CODE: DE 1243 0609 6710 0020 
>>> BIC-CODE / SWIFT: GENODEM1GLS
>>>
>>>
>>> ___
>>> Imports mailing list
>>> Imports@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/imports
>>>
>>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
> ___
> Imports mailing list
> Imports@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-- 
Elliott Plack
http://elliottplack.me
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Hydrological/hydraulic model data import

[Elliott Plack]

Courtney,

Are we talking merely the geometry of the hydrology? I think that would be
suitable if the ways are connected properly.

Elliott

On Tue, Oct 20, 2015 at 2:20 PM Pavel Machek  wrote:

> On Mon 2015-10-19 15:40:22, Rieger, Courtney wrote:
> > Hi all,
> >
> > Is it possible to upload/import a hydrological/hydraulic model into OSM?
>
> Subsets of that data are certainly welcome. For example map of rivers
> would be nice...
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
> ___
> 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] Looking for POI datasets

[Elliott Plack]

Sander,

Cool idea! I have a number of datasets in mind, but the two most foremost
are ones created by local governments to inventory all their facilities
(schools, police stations, fire depts). A lot of that gets added to the map
already, so it could provide for some good QC.

The other is a gov't maintained POI dataset used in 911 dispatch (when a
caller doesn't know the address of the POI they're in). I would one day
like to do some kind of ETL to get some of that in OSM, but I also like to
survey these things.

Let me know if you want them to test.

Elliott

On Wed, Oct 21, 2015 at 10:59 AM Sander Deryckere 
wrote:

> Hi,
>
> I'm developing a tool called POI Importer (
> http://wiki.openstreetmap.org/wiki/POI_Importer ). It's a combination of
> QA and community-powered import.
>
> The aim is that different databases of POIs will be uploaded to the tool,
> then the tool will compare it with the existing OSM data, and allows users
> to import the POI one by one in their area.
>
> I tried to combine the following:
>
>- Local verification: by showing the points on a map (instead of
>picking a random one like maproulette), the users will most likely stay
>close to the area they know well, which lowers the chance of copying 
> errors.
>- Support for multiple tags at once: many POI datasets contain
>multiple tags. Think about name, operator, opening hours, contact info, ...
>Some of that data might be already in OSM, some not.
>- Data is easy to update: The comparison with OSM happens live (thanks
>to Overpass API), so it's just a matter of updating the 3rd party data when
>there's a new dataset available
>
> So far, I've been developing with the dataset of our PT bus company (see
> http://poi-importer.github.io/#map=14/50.9343/4.0518&datasets=BE_dl )
> this data is rather dense, which was ideal to test the speed.
>
> Now I'm looking to find other datasets. Thinking of big chains with a
> number of shop locations, or certain umbrella groups representing a number
> of small enterprises. These companies will usually have no (or fewer)
> problems with giving that data away for free (it's free publicity for
> them). So I think we should be able to find some usable databases.
>
> Does anyone currently have POI datasets that could be used?
>
> Off course, I'm willing to help when anyone has questions, and I'm open to
> suggestions.
>
> Regards,
> Sander
> ___
> 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] OSM Import Question

[Elliott Plack]

Sounds great to me, POI data is hard to crowd source. Assuming the
licensing and existing data issues are taken care of, I vote yes.

Elliott Plack

On Thu, Aug 27, 2015 at 11:59 AM Jim Stob  wrote:

> Hello OSM Community,
>
>
> My name is Jim Stob and I am with Position Technologies, Inc. Position
> Tech works with large North America brands in managing their brick and
> mortar locations within the local ecosystem. We work closely with engines
> like Google and Bing as well as licensing our data to Apple, Nokia/Here,
> TomTom to name a few.
>
> We have full rights to provide our data under a Trademark and Data
> Agreement we have in place with the brands we manage.
>
> My question to the community is would you be interested in importing our
> POI data if it met or exceeded your quality expectations?
>
> Thanks,
> Jim
>
> James A Stob
> CEO
> Position Technologies, Inc.
> 2000 S Batavia St - Suite 350
> Geneva, IL 60134
> Direct 630-262-5310
> ___
> 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] Using shp2osm

[Elliott Plack]

Greetings,

I too am a GIS professional and have worked on several imports of some
government data lately. Since you're a GIS guy, I suggest looking at the
wiki [1] for my Baltimore County import under spatial workflow. I used a
ModelBuilder model in ArcGIS to chunk, simplify and project certain
features.

Instead of shp2osm, I used *ogr2osm* [2], which definitely works and is
pretty easy to set up (I'm no crack coder). List member Paul Norman made
that tool. ogr2osm can (with practically zero configuration) convert
shapefiles to .osm format. You can even write a custom translation [3] to
translate the GIS attributes to OSM friendly tags if you want.

Then for automated import, I suggest the OSM Upload Mechanical Toolkit as
used in another import I'm in the middle of [4]. It works great with the
latest API.

[1]
https://github.com/baltimorecounty/openstreetmap/wiki/Buildings-and-Addresses-Import
[2] https://github.com/pnorman/ogr2osm
[3]
https://github.com/osmlab/bmorebuildings/blob/master/address-building/ogr2osm-translations/bc-address.py
[4]
http://wiki.openstreetmap.org/wiki/Baltimore_Buildings_Import_2.0#Uploading

Questions, let me know.

Thanks,

Elliott

On Wed, Apr 8, 2015 at 4:08 PM EthnicFood IsGreat <
ethnicfoodisgr...@gmail.com> wrote:

> Hello list.  I am a newbie as far as importing into OSM, but I am also a
> GIS professional working for the City of Indianapolis and I have access to
> all our GIS layers.  I would like to import some of our layers into OSM,
> and I'm aware that I need to publish a plan first, but right now I have a
> technical question.  I want to use the shp2osm script to convert our
> shapefiles, but the OSM wiki says that the script is not compatible with
> API 0.6.  Does that mean that if I use the script and then try to import
> the data into OSM using JOSM, it won't work?
>
> Mark
> ___
> 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] [Imports-us] Baltimore Buildings and Addresses Import Proposal

[Elliott Plack]

Matthew,

Great work on this so far! Your efforts on the project are fantastic and I
am grateful for your involvement. I hope we can get some community help on
the tasks... should be fun.

Cheers,

Elliott

On Mon, Apr 6, 2015 at 1:00 PM Matthew Petroff 
wrote:

> The initial, automated phase of the import has now been completed using
> scripts from the OSM Import Toolkit [1] and my imports account [2]. A task
> has now been set up on the openstreetmap.us tasking manager for the
> manual conflation and verification phase [3].
>
> -Matthew Petroff
>
> [1] https://github.com/jremillard/osm-import-toolkit
> [2] https://www.openstreetmap.org/user/mpetroff-imports/history
> [3] http://tasks.openstreetmap.us/job/59
>
> On Wed, Mar 25, 2015 at 7:02 PM, Elliott Plack 
> wrote:
>
>> Dear Imports and Imports-US communities,
>>
>> Today a dedicated team of Baltimore area OpenStreetMap supporters and
>> mappers are proposing an import of Baltimore buildings and addresses. The
>> import background and procedures are documented on the OSM wiki:
>> https://wiki.openstreetmap.org/wiki/Baltimore_Buildings_Import_2.0
>>
>> The code is available on GitHub: https://github.com/osmlab/bmorebuildings
>>
>> Additionally, the import has been added to the import catalog:
>> https://wiki.openstreetmap.org/wiki/Import/Catalogue#Community_Imports
>>
>> The import team includes users ElliottPlack and mpetroff. The data
>> provider and owner is Jim Garcia with Baltimore City MOIT.
>>
>> Briefly, the data comes directly from MOIT free of any license, will full
>> permission for import. The data is simplified, conflated where possible,
>> and prepped for automated import. Data that conflicts with existing data is
>> set aside for manual review. It is the intention of the authors of this
>> import to utilize the OSM Tasking Server to divide up manual review tasks.
>>
>> Thanks for considerations,
>>
>> ElliottPlack
>>
>> mpetroff
>>
>> ___
>> Imports-us mailing list
>> imports...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports-us
>>
>>
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

[Imports] Baltimore Buildings and Addresses Import Proposal

[Elliott Plack]

Dear Imports and Imports-US communities,

Today a dedicated team of Baltimore area OpenStreetMap supporters and
mappers are proposing an import of Baltimore buildings and addresses. The
import background and procedures are documented on the OSM wiki:
https://wiki.openstreetmap.org/wiki/Baltimore_Buildings_Import_2.0

The code is available on GitHub: https://github.com/osmlab/bmorebuildings

Additionally, the import has been added to the import catalog:
https://wiki.openstreetmap.org/wiki/Import/Catalogue#Community_Imports

The import team includes users ElliottPlack and mpetroff. The data provider
and owner is Jim Garcia with Baltimore City MOIT.

Briefly, the data comes directly from MOIT free of any license, will full
permission for import. The data is simplified, conflated where possible,
and prepped for automated import. Data that conflicts with existing data is
set aside for manual review. It is the intention of the authors of this
import to utilize the OSM Tasking Server to divide up manual review tasks.

Thanks for considerations,

ElliottPlack

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

Re: [Imports] Maryland State Park & Nature Area Import

[Elliott Plack]

Greetings,

I finally completed the import over the weekend when I had some free time.
The data looks great and adds some color to the map where there wasn't any.
Have a look at a few areas:

Eastern Shore: http://www.openstreetmap.org/#map=11/38.3158/-75.9087
Western Md: http://www.openstreetmap.org/#map=10/39.5348/-78.8956
Patapsco: http://www.openstreetmap.org/#map=14/39.2404/-76.7529

Hooray!

Now, there is some data on County owned parks in the data that I want to
ask the community about. This data shows all county owned land that is set
aside for recreation or preservation. There are many gaps in the state and
federal parks that are covered by county parks, where having that data
would be immensely valuable.

Conversely, the data includes many small "Local Open Space" or "Drainage
and Utility" properties. These tracts are set aside during the land
subdivision process to preserve a certain % of the land for non-development
uses. There is value in having this data on OSM, such as for geocachers.
Technically the land is public and open. However, I'd only use the
leisure=park when the land is specifically a park, whereas
leisure=nature_reserve would apply to preserved land that isn't
specifically for recreation. Look at Baltimore.geojson or
Montgomery.geojson in the data below for these small properties.

Here are some geoJSON files that you can visualize on Github on top of an
OSM basemap (by Mapbox):
https://github.com/talllguy/maryland-dnr-osm-import/tree/master/dataWGS84/County%20Lands/byCounty

Thoughts on the small county properties?

Elliott


On Fri Apr 18 2014 at 3:16:39 PM Elliott Plack 
wrote:

> Greetings Import Community,
>
> *Firstly, pardon the duplicate message. The original was sent in error
> without a subject.*
>
> After SOTMUS, I have decided to resurrect the import of Maryland Dept. of
> Natural Resources land boundary data. This import will take public domain
> Maryland polygon data that represents the official boundaries of state
> parks and protected areas and will bring them into OSM using a variety of
> tags. I have documented this in the link below, complete with tables,
> diagrams, examples, and a link to the data on GitHub.
>
> *Brief Summary*: Maryland has made this data public domain. The plan is
> to import this data in *manual mode* only. Local editors will examine the
> data on an individual basis and then upload it when it meets tagging
> standards. The tagging will be fairly comprehensive. We'll either use
> leisure=park or leisure=nature_reserve depending on the data dictionary
> on the wiki. We'll also use the boundary=protected scheme and I have
> written a key for each state land type and corresponding protect_class
>  type.
>
> *Benefits:* This data in OSM will be fantastic for basemaps, as parks and
> natural protected land boundaries are often hard to discern based solely on
> imagery. Local surveys are impractical given the immense size of some of
> these areas. Coupled with trails surveyed by other local mappers, or using
> the new Strava slide tool, the OSM map can often outperform the official
> state maps in terms of accuracy and informational content.
>
> http://wiki.openstreetmap.org/wiki/Maryland_State_Parks
>
>
> https://github.com/talllguy/maryland-dnr-osm-import/tree/master/dataWGS84/DNR%20Lands%20and%20Conservation%20Easements
>
> Looking forward to any comments.
>
> Thanks,
>
> --
> Elliott Plack
> http://about.me/elliottp
>
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] [Imports-us] New Orleans: importing buildings and addresses

[Elliott Plack]

Matt: good work on getting this started. It is definitely unfortunate that
the address points are not spatially paired with the buildings. In my
Baltimore County import[1], address points are placed at the building
centroid unless there are multiple, (then they are placed at the unit
centroid). If the spatial component of the address node is unspecific, e.g.
it is at the parcel center, than I recommended conflating them if they do
fall within the building footprint, as I did [2].

Since ZIP Codes aren't part of the source data, I would not spend a ton of
time trying to source them. It might actually distort the authoritativeness
of the original data in that you would be combining a verified source and a
derived source. I think you should proceed without them and utilize JOSM
and the select within tool to add them as a separate import project,
thereby keeping the lineage separate.

Kindly,

Elliott

[1] = http://www.openstreetmap.org/#map=18/39.37694/-76.60895
[2] =
https://github.com/baltimorecounty/openstreetmap/wiki/Buildings-and-Addresses-Import#data-conflation


[image: --]
Elliott Plack
[image: http://]about.me/elliottp
<http://about.me/elliottp?promo=email_sig>


On Thu, Oct 23, 2014 at 9:09 AM, Richard Welty 
wrote:

>  On 10/23/14 8:05 AM, Eric Ladner wrote:
>
>  On Wed, Oct 22, 2014 at 7:20 PM, Matt Toups  wrote:
>
>>
>> Unfortunately there are no ZIP codes in the address data set.
>>
>>
>  Again, an area where a GIS database rocks.  Import a zip code data set
> into another table, at extract time get the zip code for the particular
> address node in question with a ogr2osm filter.
>
>   what zip code data sets exist that are appropriately licensed? ZCTA
> from TIGER is public domain, but it has some limitations (although i'm
> going to be using it anyway, but not for import to OSM.)
>
> richard
>
> -- rwe...@averillpark.net
>  Averill Park Networking - GIS & IT Consulting
>  OpenStreetMap - PostgreSQL - Linux
>  Java - Web Applications - Search
>
>
> ___
> Imports-us mailing list
> imports...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports-us
>
>
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Ottawa Bike Parking Import

[Elliott Plack]

Thanks Andy. I should have said, "Pardon my unbridled enthusiasm." :)

On Thu, Sep 25, 2014 at 10:53 AM, Andy Allan  wrote:

> > Please forgive my enthusiasm
>
> No worries, nothing wrong with a bit of enthusiasm and an desire to
> help other people out!
>
> Thanks,
> Andy
>



-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Ottawa Bike Parking Import

[Elliott Plack]

Andy,

Thanks for the response. Please forgive my enthusiasm, and you're quite
right that proper documentation is a must, as well as considering the
existing data. I ran a query and there are quite a few existing
installations on OSM. Map: http://overpass-turbo.eu/s/5b3

I should start by saying I only jumped in in the middle of the project to
help Clark with the data. I've never even been to Ottawa. I had assumed
that some due diligence had already taken place, like checking for existing
data etc. If it were my project, I would have ran the query, got the
existing data, and compared that before even posting anything here.

And I was wrong to say it was a "few clicks." That is never true. :) If the
data was conflated, verified, and accurate, it would be, but there'd be
much work (and clicks) to get to that point.

Clark: Definitely write up a wiki on
http://wiki.openstreetmap.org/wiki/Main_Page. Detail the source of the
data, licenses, community support and how to tackle existing data.

Kindly,

Elliott

On Thu, Sep 25, 2014 at 6:24 AM, Andy Allan  wrote:

> On 24 September 2014 22:31, Elliott Plack  wrote:
> > Clark,
> >
> > Quick tip, always reply all to these list emails so it goes back into the
> > list.
> >
> > Definitely use the PNG! I'll license it as CC0.
> >
> > For approval we should wait a few days for others to comment. Also we'll
> > want to check if there's any existing data that would be duplicated.
> >
> > I can do the import for you too, no problem. It's just a few clicks.
> >
> > Finally you'll want to write a wiki page on the OSM wiki. Just summarize
> > what you said in the first email.
>
> I think you've got it back-to-front - there's no way that anyone can
> review this *before* you write the wiki page!
>
> Also, I just had a quick look. From your image I count at least 7 bike
> parking images within a few metres of the intersection of Bank and
> Queen Street, but when I look at google street view I see only bikes
> chained to trees and some railings outside a bank - further away
> there's some actual parking infrastructure but it's not clear to me
> how they all correspond and what counts as "parking" here. Again,
> questions to answer on a wiki page are required.
>
> There's already existing bike parking in Ottawa, so there will need to
> be some sort of merging/de-duplication.
>
> And finally, best not so say "It's just a few clicks" because
> honestly, that's never the case, and secondly, it's not the attitude
> we're trying to promote!
>
> Thanks,
> Andy
>



-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Ottawa Bike Parking Import

[Elliott Plack]

Clark,

Quick tip, always reply all to these list emails so it goes back into the
list.

Definitely use the PNG! I'll license it as CC0.

For approval we should wait a few days for others to comment. Also we'll
want to check if there's any existing data that would be duplicated.

I can do the import for you too, no problem. It's just a few clicks.

Finally you'll want to write a wiki page on the OSM wiki. Just summarize
what you said in the first email.

Cheers,
Elliott

On Wednesday, September 24, 2014, Clark Trivers  wrote:

>  That is fantastic! Thank you, Elliott. However I can't open the .OSM
> file. It seems I have reached the point where I feel like a novice. Could
> you advise the next steps I should take? What is required for list
> approval? In the meantime I'll continue studying this
> <http://wiki.openstreetmap.org/wiki/Import/Guidelines>. Also, do you mind
> if I use your ArcMap .png on our website as a teaser before all the data is
> uploaded?
>
>
>  Cheers!
>
>
>  --
> *From:* Elliott Plack  >
> *Sent:* Wednesday, September 24, 2014 2:24 PM
> *To:* Clark Trivers
> *Cc:* Imports OpenStreetMap.org; Alex Barth
> *Subject:* Re: [Imports] Ottawa Bike Parking Import
>
>  Clark,
>
>  You can definitely use this data for automated importing (provided this
> list approves). In fact, because I love data and bike parking, I have
> converted your spreadsheet into a .OSM file for easy JOSM importing. Here's
> what I did:
>
>  1. Split the coordinates column in Excel into two columns, lat and long
> 2. Fixed the columns names and contents to be compatible with OSM
> structures (e.g. you put the key in the first row (heading) and the values
> in the subsequent rows)
> 3. Export to CSV
> 4. Use ogr2ogr to convert the CSV to SHP. See -
> http://gis.stackexchange.com/questions/327/how-can-i-convert-an-excel-file-with-x-y-columns-to-a-shapefile
> 5. Use ogr2osm to convert the SHP to OSM
> 6. Verify the tagging in JOSM - fix shapefile field name truncation
> 7. Validate
> 8. Save
> 9. Write this email
>
>  This data will look great on the map! I took a screenshot of how it fits
> spatially over OSM (via ArcMap) which is attached. Pardon the lame
> symbology.
>
>  Attached is the OSM file, and all the intermediary files I created.
>
> On Wed, Sep 24, 2014 at 12:18 PM, Clark Trivers  > wrote:
>
>>  Hey Elliott,
>>
>>
>>  Thanks for that tip!
>>
>>
>>  I made some changes. Do you think this spreadsheet could just be
>> uploaded all at once? Would each row need to be put in as a node manually
>> regardless of spreadsheet formatting?
>>
>>
>>  I'm looking for a quick way of getting all these points on a map
>> without having to go through all the rows one-by-one.
>>
>>
>>  Thanks again,
>>
>>
>>  Clark
>>  --
>> *From:* Elliott Plack > >
>> *Sent:* Sunday, September 21, 2014 10:59 AM
>> *To:* Clark Trivers
>> *Cc:* imports@openstreetmap.org
>> 
>> *Subject:* [Imports] Ottawa Bike Parking Import
>>
>>   Clark,
>>
>>  This looks cool. One important step is to translate the types of bike
>> parking in the document to the types that OSM uses. Here is a wiki page
>> with pictures of each type. For instance, loop and post is probably
>> "stands". http://wiki.openstreetmap.org/wiki/Key:bicycle_parking
>>
>>  Maybe add a column for that or write us a data dictionary for each of
>> the Ottawa types.
>>
>>  Thanks,
>>
>>  Elliott
>>
>> On Tuesday, September 16, 2014, Clark Trivers  wrote:
>>
>>>  Hi there,
>>>
>>>  I work for the Ottawa Centre EcoDistrict and we recently did an
>>> assessment of all bike parking in downtown Ottawa. I was hoping to upload
>>> our data, share it with our partners, and invite the community to update as
>>> needed. I have attached our data in excel.
>>>
>>>  I'm hoping you could give me some pointers on how best to share our
>>> findings in a way that allows anyone to keep the information up to date.
>>>
>>>  Thanks,​
>>>
>>>
>>>
>>>   *Clark Trivers *| *Program Coordinator*
>>> Ottawa Centre EcoDistrict
>>> p. 613-256-6262 x3 | c. 613-292-9130
>>> www.ottawaecodistrict.org | @ott_ecodistrict
>>> <http://twitter.com/ott_ecodistrict>
>>>
>>
>>
>> --
>> Sent from iPhone; kindly excuse tyops.
>>
>
>
>
>  --
> Elliott Plack
> http://about.me/elliottp
>


-- 
Sent from iPhone; kindly excuse tyops.
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

[Imports] Ottawa Bike Parking Import

[Elliott Plack]

Clark,

This looks cool. One important step is to translate the types of bike
parking in the document to the types that OSM uses. Here is a wiki page
with pictures of each type. For instance, loop and post is probably
"stands". http://wiki.openstreetmap.org/wiki/Key:bicycle_parking

Maybe add a column for that or write us a data dictionary for each of the
Ottawa types.

Thanks,

Elliott

On Tuesday, September 16, 2014, Clark Trivers > wrote:

>  Hi there,
>
>  I work for the Ottawa Centre EcoDistrict and we recently did an
> assessment of all bike parking in downtown Ottawa. I was hoping to upload
> our data, share it with our partners, and invite the community to update as
> needed. I have attached our data in excel.
>
>  I'm hoping you could give me some pointers on how best to share our
> findings in a way that allows anyone to keep the information up to date.
>
>  Thanks,​
>
>
>
>   *Clark Trivers *| *Program Coordinator*
> Ottawa Centre EcoDistrict
> p. 613-256-6262 x3 | c. 613-292-9130
> www.ottawaecodistrict.org | @ott_ecodistrict
> 
>


-- 
Sent from iPhone; kindly excuse tyops.
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Baltimore County Maryland Hydrology Import

[Elliott Plack]

Christoph,

Thank you for the analysis! I have put this one on hold after reviewing
your comments. I need to revisit the tagging and the automation before
proceeding further.

- polygon issue: There is a separate dataset for polygons that I will use
going forward. I'll ditch all the polygon type data from the "line" layer.
- tunnels: in the data, water in culverts do not have a specified type, so
these require manual QC before importing
- names: yes, clearly there are quite a few empty names. The JOSM validator
does take care of them though.
- artificial: The data does not differentiate between small streams,
drains, and other manmade features, so I had been calling them all stream,
and then going back and changing the small ones to =drain
- basin: This is probably a poor tag choice. The data lists these as
stormwater management ponds though, so they could be dry or wet, and basin
is the tag on the wiki. I've been manually changing the wet ones to pond
when applicable. This will require more looking at.

Kindly,

Elliott

On Sat, Sep 6, 2014 at 4:26 PM, Christoph Hormann 
wrote:

> On Friday 05 September 2014, Elliott Plack wrote:
> > 3. Here is the
> > resulting OSM file of that translation:
> >http://1drv.ms/1lLHSIm
>
> This seems to be fairly incomplete/unfinished.  A few observations:
>
> - no correct polygons for the water surfaces consisting of more than one
> way, tag natural=water on unclosed ways.
> - tunnel sections of waterways have no waterway tag
> - lots of empty name tags but only few actual waterway names.
> - waterways mostly end at the water area edge and are not connected to
> the destination waterway.
> - there are quite a few clearly artificial waterways tagged
> waterway=stream.
> - use of landuse=basin seems strange - is apparently used for both areas
> with permanent and sporadic water cover.
>
> > Questions:
> >
> > We have data on where the coastline is comprised of bulkhead, like
> > where the coastline is unnatural. Is that relevant to the project? I
> > haven't seen a bulkhead type tag but it could be considered a
> > seawall.
>
> There are no established supplementary tags to characterize the
> coastline itself - an artificial coastline often means there is some
> feature on the coast that should be mapped like man_made=dyke or
> man_made=breakwater and then there is no need to tag the line in
> addition.  For a bulkhead on its own barrier=retaining_wall would seem
> the most fitting established tag but barrier=bulkhead would actually
> seem quite appropriate.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Imports mailing list
> Imports@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>



-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

[Imports] Baltimore County Maryland Hydrology Import

[Elliott Plack]

Now that the building and address import is complete, I am moving on to
some of the planimetrics that make OSM look good but also contain useful
information. Parts of the county have a very good, dense network of
streams, traced by a few users, but it can be difficult to spot some
streams amidst tree cover on air photos. In these areas where hydrology
(streams, rivers, ponds, storm water management, piers, etc) exist, I am
proposing to import public domain Baltimore County hydrology, while taking
care not to overwrite anyones hard work.

Before I write up a wiki, here are the basic details:


   1. I made a model that simplifies the polyline hydrology feature class
   with a simplification factor of two feet to prevent "overnoding". In
   experimenting, two feet between nodes keeps the data simple on the map, but
   typically doesn't result in it looking too jagged. The source data is drawn
   with a digital pen and then converted to polyline, so any given 10 foot
   segment might have 500 nodes in the source.
   2. I ran Paul Norman's ogr2osm on the result from step one, with a
   custom translation to convert the various feature types in the source data
   to something compatible with the OSM key/value data model. Here is that
   translation: https://gist.github.com/talllguy/52066d13d323f1535f3a
   3. Here is the resulting OSM file of that translation:
   http://1drv.ms/1lLHSIm
   4. In JOSM I look for a stream system that is missing. I disconnect the
   last segment that would intersect an existing water feature already on the
   map, like a river or coastline. I use the 'select all connecting ways' tool
   to select the entire system and then copy that to a new layer and download
   existing OSM data to that layer. (some tags are purposefully translated
   with no type, so I have to go back and correct them individually and check
   the data)
   5. I run the validator to look for issues. Null names, and nodes that
   don't quite connect are easy to find this way.
   6. Upon solving all validator issues I import the system.

Notes:

   - I'm not going to mess with importing coastline. Our coast is pretty
   good and there are too many ways to introduce bugs when importing coastline.
   - Some of the features like boat docks, ramps, and piers may be too
   complicated for import. Those I'd address individually and may just use a
   node for leisure=slipway.
   - For larger rivers where there is a riverbank in the data, I'll use the
   approved water=* tagging.

Questions:

We have data on where the coastline is comprised of bulkhead, like where
the coastline is unnatural. Is that relevant to the project? I haven't seen
a bulkhead type tag but it could be considered a seawall.

As a test, I uploaded a small stream system that had not been traced at
all, the Sawmill Branch, so you all can see how it'd look on the map. That
system is here: http://www.openstreetmap.org/#map=15/39.5217/-76.5440

This is will be a very manual process and as a steward of open data, I will
take great care not to undo other mappers hard work.

-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Baltimore County Maryland Building and Address Import

[Elliott Plack]

Quick update: The import is finished! I've been doing some QC and it really
is great to look at, and so useful. OSM in Baltimore County has better
addresses than any of the other online maps. Hooray for open source!
http://www.openstreetmap.org/#map=15/39.4379/-76.6223

I'll write a diary post soon detailing some of the ins and outs of this. It
was really fun.


On Sat, Aug 9, 2014 at 12:27 AM, Elliott Plack 
wrote:

> Greetings Fellow Mappers,
>
> As some of you may know, I am a GIS Specialist for Baltimore County, Md.
> Since we released our data as public domain around a year ago, I've been
> meaning to do this import. This week I had some free time and decided to
> kick it off, just in time for the 10th anniversary of OpenStreetMap.
>
> I've been working on this project in the open, as much as possible: at
> https://github.com/baltimorecounty/openstreetmap
>
> The details of the import procedures are found on the github wiki, which I
> will move to the OSM wiki periodically:
> https://github.com/baltimorecounty/openstreetmap/wiki/Buildings-and-Addresses-Import
>
> The intent of this import is to provide OSM users with the best and most
> accurate street and building data my office has to offer. Our data is
> thoroughly vetted, verified, and tested. It has to be good, because County
> emergency staff rely on it in the field.
>
> While preparing the data for import and consideration by the community,
> much thought was put into the content, spatially and in data terms. For
> instance, county address data is stored in all caps, with standard
> abbreviations. The road names' case was changed intelligently, so that
> roads like "McDonough" would read correctly. Also, all abbreviations were
> expanded. More details on the wiki.
>
> (A note on abbreviations given the recent discussions on various OSM
> mailing lists. Baltimore County is meticulous and methodical about using
> abbreviations in its data. Words like Mount and Saint are never
> abbreviated. Only directionals (pre + post) and types are abbreviated. This
> made expansion a breeze.)
>
> Please review the wiki and github. Data is on Microsoft OneDrive
>
> https://github.com/baltimorecounty/openstreetmap/wiki/Buildings-and-Addresses-Import
> https://github.com/baltimorecounty/openstreetmap/
> http://1drv.ms/XOQD9J
>
> I welcome all feedback, and while I've tried to get it right the first
> time, there may be room for improvement.
>
> Thanks,
>
> --
> Elliott Plack
> http://about.me/elliottp
>



-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

[Imports] Baltimore County Maryland Building and Address Import

[Elliott Plack]

Greetings Fellow Mappers,

As some of you may know, I am a GIS Specialist for Baltimore County, Md.
Since we released our data as public domain around a year ago, I've been
meaning to do this import. This week I had some free time and decided to
kick it off, just in time for the 10th anniversary of OpenStreetMap.

I've been working on this project in the open, as much as possible: at
https://github.com/baltimorecounty/openstreetmap

The details of the import procedures are found on the github wiki, which I
will move to the OSM wiki periodically:
https://github.com/baltimorecounty/openstreetmap/wiki/Buildings-and-Addresses-Import

The intent of this import is to provide OSM users with the best and most
accurate street and building data my office has to offer. Our data is
thoroughly vetted, verified, and tested. It has to be good, because County
emergency staff rely on it in the field.

While preparing the data for import and consideration by the community,
much thought was put into the content, spatially and in data terms. For
instance, county address data is stored in all caps, with standard
abbreviations. The road names' case was changed intelligently, so that
roads like "McDonough" would read correctly. Also, all abbreviations were
expanded. More details on the wiki.

(A note on abbreviations given the recent discussions on various OSM
mailing lists. Baltimore County is meticulous and methodical about using
abbreviations in its data. Words like Mount and Saint are never
abbreviated. Only directionals (pre + post) and types are abbreviated. This
made expansion a breeze.)

Please review the wiki and github. Data is on Microsoft OneDrive
https://github.com/baltimorecounty/openstreetmap/wiki/Buildings-and-Addresses-Import
https://github.com/baltimorecounty/openstreetmap/
http://1drv.ms/XOQD9J

I welcome all feedback, and while I've tried to get it right the first
time, there may be room for improvement.

Thanks,

-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Vermont Town boundaries from VCGI

[Elliott Plack]

Andrew,

I loaded your data into JOSM and its really something! Good work. I think
if you poke around, you'll see that many of the place=* places have already
been imported by the GNIS import. Most of them will be (perhaps
incorrectly) place=hamlet, unless another editor upgraded them.

For instance, the town of Northfield (where I briefly lived) has a node
with the proper attributes: https://www.openstreetmap.org/node/158851899

Now, I just noticed in your data the names include the census place type,
like Northfield *Village, *Barton *Village, *etc. I believe those are place
types and not the actual administrative name. in the census data, they
spell the types with lowercase to indicate this (I believe). Head to
http://factfinder2.census.gov/faces/nav/jsf/pages/index.xhtml and type in
"Northfield vi" and you'll see what I mean. Perhaps you want to look into
that.

Kindly,

Elliott


On Mon, May 5, 2014 at 1:53 PM, Andrew Guertin wrote:

> I've removed place=* from all elements.
> http://www.uvm.edu/~aguertin/osm/vermont-towns-counties-villages4.osm
>
>
> Having seen everyone's objections and thought about it more, I still think
> that within the context of a Vermont-only map, it would make most sense to
> keep things labelled with place, but to better match how they're used
> elsewhere I'll leave them out.
>
>
> --Andrew
>
> ___
> Imports mailing list
> Imports@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>



-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Vermont Town boundaries from VCGI

[Elliott Plack]

Martin, thanks for pointing that out. I should clarify. I'm not against
this import so long as the community thinks boundaries are good for OSM. As
for the place=* tags, if there isn't a conflict in placing them both on the
boundary and a node, then so be it.


On Mon, May 5, 2014 at 12:11 PM, Martin Koppenhoefer  wrote:

>
> 2014-05-04 20:59 GMT+02:00 Elliott Plack :
>
> In my experience, place=hamlet,village,town,city are *better placed as
>> nodes* at the boundary centroid, rather than with ways representing the
>> boundary. Mapnik and Mapbox use the nodes rather than the boundary lines to
>> render. I am pretty familiar with place=* tags. Importing the boundaries
>> are nice in terms of getting that data out there for all to see, but for
>> place mapping consider adding nodes at the centroids.
>>
>
>
>
> I think that both are valueable information, a place polygon (not to
> confuse with the administrative boundary, which often incorporates also
> fields, forests etc.) could be used to describe the area of the settlement
> (shape and size) and the place node can be used to indicate the more or
> less obvious centre point (e.g. for routing without a specific address, for
> low scale maprendering / labeling etc.).
>
> As all settlements do have a spatial extension I fail to understand how
> omitting this would be "better".
>
> cheers,
> Martin
>
>


-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Vermont Town boundaries from VCGI

[Elliott Plack]

+1 on Frederik

In my experience, place=hamlet,village,town,city are *better placed as
nodes* at the boundary centroid, rather than with ways representing the
boundary. Mapnik and Mapbox use the nodes rather than the boundary lines to
render. I am pretty familiar with place=* tags. Importing the boundaries
are nice in terms of getting that data out there for all to see, but for
place mapping consider adding nodes at the centroids.

Here's a handy guide to place tags:

hamlet 100-200 people (also consider =neighbourhood (no population limit))
village 200-10,000
town 10,000-100,000
city 100,000+

I've added nodes for the CDPs and CIPs around Baltimore City.

http://www.openstreetmap.org/#map=11/39.3168/-76.6647
http://a.tiles.mapbox.com/v3/villeda.map-atyd5cky.html#11/39.3356/-76.5905

For this project, consider adding nodes and then use the is_in schema. I've
seen people use relations with the node and boundary as well.

Best,

Elliott


On Sun, May 4, 2014 at 5:25 AM, Frederik Ramm  wrote:

> Hi,
>
> On 04.05.2014 07:08, Andrew Guertin wrote:
> > As far as I can tell that addresses all the comments from previously.
> > Any more?
>
> I have not followed the discussion in detail so I'm sorry if I repeat
> something already said, but be aware that place=* tags tend to be on
> nodes not multipolygons, with the node placed roughly at the population
> center, the central square of a city or whatever.
>
> With place=* on multipolygons, renderers will try their best and place a
> label at the center of the polygon, if they label it at all, which will
> end up with a town label for "Duxbury" in the middle of the woods.
>
> When I see "boundary=administrative, admin_level 8" then I know this is
> just a boundary and doesn't say much about whether people live there at
> all, and how many, and where. But when I see "place=town" then I expect
> a proper town with (usually) a pub and a church.
>
> If I were doing this import, I would probably take the time and separate
> the place=* tags into nodes of their own, manually placing them at
> something that looks like a populated place, and remove place=* from the
> multipolyongs; or if I didn't have the time for that sort of work, I'd
> not add any place=* at all.
>
> But I'm not very familiar with the place=* usage in the US and if this
> is the done thing over there, feel free to ignore me.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Imports mailing list
> Imports@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>



-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

[Imports] Maryland State Park & Nature Area Import

[Elliott Plack]

Greetings Import Community,

*Firstly, pardon the duplicate message. The original was sent in error
without a subject.*

After SOTMUS, I have decided to resurrect the import of Maryland Dept. of
Natural Resources land boundary data. This import will take public domain
Maryland polygon data that represents the official boundaries of state
parks and protected areas and will bring them into OSM using a variety of
tags. I have documented this in the link below, complete with tables,
diagrams, examples, and a link to the data on GitHub.

*Brief Summary*: Maryland has made this data public domain. The plan is to
import this data in *manual mode* only. Local editors will examine the data
on an individual basis and then upload it when it meets tagging standards.
The tagging will be fairly comprehensive. We'll either use leisure=park or
leisure=nature_reserve depending on the data dictionary on the wiki. We'll
also use the boundary=protected scheme and I have written a key for each
state land type and corresponding protect_class type.

*Benefits:* This data in OSM will be fantastic for basemaps, as parks and
natural protected land boundaries are often hard to discern based solely on
imagery. Local surveys are impractical given the immense size of some of
these areas. Coupled with trails surveyed by other local mappers, or using
the new Strava slide tool, the OSM map can often outperform the official
state maps in terms of accuracy and informational content.

http://wiki.openstreetmap.org/wiki/Maryland_State_Parks

https://github.com/talllguy/maryland-dnr-osm-import/tree/master/dataWGS84/DNR%20Lands%20and%20Conservation%20Easements

Looking forward to any comments.

Thanks,

-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] [Imports-us] (no subject)

[Elliott Plack]

Please ignore this mailing. I will resend with a proper subject.


On Fri, Apr 18, 2014 at 2:46 PM, Elliott Plack wrote:

> Greetings Import Community,
>
> After SOTMUS, I have decided to resurrect the import of Maryland Dept. of
> Natural Resources land boundary data. This import will take public domain
> Maryland polygon data that represents the official boundaries of state
> parks and protected areas and will bring them into OSM using a variety of
> tags. I have documented this in the link below, complete with tables,
> diagrams, examples, and a link to the data on GitHub.
>
> *Brief Summary*: Maryland has made this data public domain. The plan is
> to import this data in *manual mode* only. Local editors will examine the
> data on an individual basis and then upload it when it meets tagging
> standards. The tagging will be fairly comprehensive. We'll either use
> leisure=park or leisure=nature_reserve depending on the data dictionary
> on the wiki. We'll also use the boundary=protected scheme and I have
> written a key for each state land type and corresponding protect_classtype.
>
> *Benefits:* This data in OSM will be fantastic for basemaps, as parks and
> natural protected land boundaries are often hard to discern based solely on
> imagery. Local surveys are impractical given the immense size of some of
> these areas. Coupled with trails surveyed by other local mappers, or using
> the new Strava slide tool, the OSM map can often outperform the official
> state maps in terms of accuracy and informational content.
>
> http://wiki.openstreetmap.org/wiki/Maryland_State_Parks
>
>
> https://github.com/talllguy/maryland-dnr-osm-import/tree/master/dataWGS84/DNR%20Lands%20and%20Conservation%20Easements
>
> Looking forward to any comments.
>
> Thanks,
>
> --
> Elliott Plack
> http://about.me/elliottp
>
> ___
> Imports-us mailing list
> imports...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports-us
>
>


-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

[Imports] (no subject)

[Elliott Plack]

Greetings Import Community,

After SOTMUS, I have decided to resurrect the import of Maryland Dept. of
Natural Resources land boundary data. This import will take public domain
Maryland polygon data that represents the official boundaries of state
parks and protected areas and will bring them into OSM using a variety of
tags. I have documented this in the link below, complete with tables,
diagrams, examples, and a link to the data on GitHub.

*Brief Summary*: Maryland has made this data public domain. The plan is to
import this data in *manual mode* only. Local editors will examine the data
on an individual basis and then upload it when it meets tagging standards.
The tagging will be fairly comprehensive. We'll either use leisure=park or
leisure=nature_reserve depending on the data dictionary on the wiki. We'll
also use the boundary=protected scheme and I have written a key for each
state land type and corresponding protect_class type.

*Benefits:* This data in OSM will be fantastic for basemaps, as parks and
natural protected land boundaries are often hard to discern based solely on
imagery. Local surveys are impractical given the immense size of some of
these areas. Coupled with trails surveyed by other local mappers, or using
the new Strava slide tool, the OSM map can often outperform the official
state maps in terms of accuracy and informational content.

http://wiki.openstreetmap.org/wiki/Maryland_State_Parks

https://github.com/talllguy/maryland-dnr-osm-import/tree/master/dataWGS84/DNR%20Lands%20and%20Conservation%20Easements

Looking forward to any comments.

Thanks,

-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

[Imports] Baltimore City GIS Data

[Elliott Plack]

Greetings Fellow Mappers!

Abstract: I have come across a large dataset of *public domain* data from
Baltimore City Government that I'd like to import.

Hello all. Some background: I have been mapping on the OSM platform for a
few months, and really enjoy it. I have a bachelor's degree in Geography,
and work in the GIS industry, however my love for maps is lifelong. I'll
never forget the joy when I first experienced a slippy map service on the
web (Google Maps) after toiling with Mapquest's pan and zoom interface for
so long. I can spend hours exploring maps, and I often do.

I got into OSM mapping recently on a more regular basis (daily?) when
Foursquare announced they were switching to map tiles based on OSM data.
When I realized Mapbox was using OSM, I was thrilled. That's because
previously I was using Google Map Maker to make edits to Google Maps.
However now that the web seems to be moving toward open, I went with it.

I work for Baltimore County Government, in the State of Maryland, USA.
Baltimore city and county are separate political entities, though adjacent
geographically. Therefore, I do not work for the government agency that
maintains this data. I've lived in the city and am moving back, motivating
me further to look into this.

My primary goal is converting the building shapefiles to OSM, which the
city puts out on its website for free. The licence is stated to be "Public
Domain". There are loads of other datasets available that I would
definitely consider adding to the mix. I am aware that too much data can be
a bad thing on OSM, as it may discourage people from editing further. The
data is at https://data.baltimorecity.gov/browse?category=Geographic

I have done a fair bit of reading on the wiki about importing, and am by no
means going to just do it. I look forward to engaging this community as
well as the local one. I hope to put my GIS experience and local knowledge
as well as passion for OSM behind this project.

So, what should my starting points be? I'll definitely contact some people
I know at the city GIS department for license clarification. By the way,
Google has their parcel data in Google Maps, which it charges for, so I
have a feeling that using it for a free cause will not be and issue.

What else?

Thank you,

-- 

Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

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

[Elliott Plack]

I like keeping the address separate, since NYC GIS put in the work to give
the spatial locations of the addresses a meaning other than just the
centroid.

Here seems to be an example of where the imports have begun:
http://www.openstreetmap.org/#map=18/40.64105/-73.96687


On Mon, Oct 14, 2013 at 1:01 PM, Serge Wroclawski  wrote:

> There's a bit of context missing from this conversation, so I want to
> fill people in on what happened, and then we can discuss the technical
> merits.
>
> Alex made his proposal (with my endorsement) before the import
> happened. Alex suggestebut then modified the data to this alternate
> way before the import event. So now we have both kinds of addresses in
> NYC. You can see some of the pre-import discussion at:
> https://github.com/osmlab/nycbuildings/issues/15
>
> We also have an import event to show what happens with users and the data.
>
> On Mon, Oct 14, 2013 at 12:35 PM, Alex Barth  wrote:
>
> > Now there's reason to revisit this decision: the data steward (Colin
> Reilly
> > from NYC GIS) told me that NYC GIS took great care to place addresses at
> > about where the entrance of the building sits.
>
> We have a tag "entrance", but when I suggested tagging the entraces as
> entrances,  Alex suggested that many of the points were not entrances,
> but centroids.
>
> If they're addresses, I say tag them as addresses. Then we can
> encourage mappers on the ground to refine the entrances to match
> ground truth, and also to add service entrances, etc.
>
> > This makes me think that there's value in not tossing the address
> location
> > information but keep it in all cases, even if there is only one address
> per
> > building.
> >
> > Here is a comparison of the two options. I'd like to discuss and decide
> at
> > tonight's imports hangout.
> >
> > ## Option 1: Merge addresses into buildings where possible
> >
> > In cases where there is one address point within a building polygon, we
> take
> > address attributes, assign it to the building polygon and toss the
> address
> > point.
> >
> > Pros:
> >
> > a) This is how a lot of buildings are done in OSM
> > b) Not regarding standing practice, merging addresses into buildings is
> an
> > exception from the generally applicable method of doing separate address
> > points.
> >
> > Cons:
> >
> > a) we lose data
>
> If we tag the entrances as entrances, as suggested on the issue 15, we
> lose no data.
>
> > b) makes it harder for NYC GIS to leverage OSM
>
> > ## Option 2: Always keep address points separate
> >
> > In this case we never merge addresses to building polygons, instead
> always
> > keep them as separate entities.
> >
> > Pros:
> >
> > a) this is the NYC GIS way, making it nicer for GIS folks to use OSM
> > b) this is the generally applicable method. No matter whether we have
> one or
> > multiple addresses you can expect to find a separate node carrying
> address
> > information.
> > c) retains useful information
> >
> > Cons:
> >
> > a) Diverges (but does not violate [1]) common OSM practice
>
> b) We see users mistagging addresses
>
> In NYC, at the import, I've seen users tagging the address points with
> building information, such as the type of building it is
> (building=residence).
>
> This confusion is probably going to continue, leading to more problems
> in OSM where the attributes of the building are placed off the
> building.
>
> c) We see multiple addresses
>
> In the NYC import, I've found multiple addresses in/near a building.
> This is from previous data, and needs cleanup. Multiple address points
> aren't wrong when there's a POI and a building, but without a
> building, it's confusing
>
> d) It adds an extra step to data consumers
>
> If you tag the building with an address, you can get the address of it
> by looking at it. And if you have a POI within the geometry of the
> building, you can get it by looking at the building container, if the
> node doesn't have it.
>
> With nodes as points, you have to look at the poi node, then look at
> the building, see that the building has no address, then look for a
> node
>
> If you tag the node as is done here, you have to look at the building,
> see it has no address data, then look for nodes within it, and see if
> they do.
>
> e) It adds no explicit value without entrance tag
>
> Tagging entrances as values with an address is useful. Not only does
> it have value on its own, but you can even add a tag to indicat

Re: [Imports] SASA bus stops import

[Elliott Plack]

Bus mapping expert here :) bus stops, in my experience, are hard to map in OSM 
and can clutter urban centers. I like to see people add routes though. You can 
do a lot of cool stuff with the routes, like make better bus maps, or get a 
more detailed map of the route. 

—
Elliott Plack
Sent from Mailbox on iPhone 5
about.me/elliottp

On Fri, Sep 27, 2013 at 6:57 PM, Jason Remillard
 wrote:

> Hi Martin,
> I am not a bus tagging expert 
> - I think you would be able to put operator=SASA on all of the nodes.
> - The name tag should be what appears on the sign at the stop. Not
> sure if they sign it in both languages with a hyphen or not.
> - You should see if SASA has a GTFS feed and see what they are using
> for station id. If it is the SASA:ref, then you may want to include it
> as some kind of gtfs tag, or just use it in the ref tag. Being able to
> link OSM to the GTFS feed would be useful.
> - I thought the bus routes were setup with relations, rather than
> route_ref tag.  Not sure if the route_ref is actually used or not? It
> is perfectly ok to import just the stations leaving out the routes.
> Thanks
> Jason
> On Fri, Sep 27, 2013 at 4:12 AM, Martin Raifer  wrote:
>> Hello!
>>
>> We are planning to import the bus stops from the "open.sasabz.it" dataset.
>> These are bus stops served by SASA, a local public bus service operator in
>> South Tyrol, Italy. The dataset is originally only available as cc-by-sa-nc,
>> but they gave us the permission to import all 889 of their bus stops into
>> OSM. Read the import plan for more information:
>>
>>
>> https://wiki.openstreetmap.org/wiki/AltoAdige_-_Südtirol/SASA_Bus_Stops_Import
>>
>> As this is my first OSM-import I'd appreciate comments :)
>>
>> Best wishes,
>> Martin
>>
>> ___
>> 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] GPX imports from Uber

[Elliott Plack]

This sounds like a great idea! We all know one or two GPS traces can
be inadequate for detailed mapping, especially in downtown areas where you
cannot see in between buildings on the imagery. Having lots of them would
be really useful.


On Thu, Jun 20, 2013 at 6:29 PM, Jason Remillard
wrote:

> Hi Jed,
>
> This Sounds great! We don't get too many bulk GPX imports. I have not done
> one myself. Just shooting from hip.
>
> -  Ian Dees does a lot of stuff with GPS data.
> - We need to make sure the license of the GPX files is ok for uploading.
> - You will need a dedicated OSM account.
> - You will probably need to write some scripts to upload the GPX files to
> the OSM API server.
>
> http://wiki.openstreetmap.org/wiki/API_v0.6#GPS_traces
>
> - As far as scrubbing them, I assume at the very least you will want to
> reset the time stamps so that all your traces start form the same time/day.
>
> - How much data do you have?
>
> Thanks
> Jason
>
>
>
> On Thu, Jun 20, 2013 at 5:07 PM, Jed Horne  wrote:
>
>> Hi,
>>
>> my name is Jed Horne and I am a data scientist with Uber (http://uber.com).
>>  My company makes an iPhone app that allows users to make on-demand
>> requests for taxis, luxury sedans, and other vehicles.  We currently
>> operate in 25+ cities in the United States, Europe, Asia, and Australia.
>>
>> We have GPS traces going back about three years from our drivers, and I
>> am interested in contributing back to the OSM community.  I was planning on
>> writing a script to anonymize and clean up our traces and export as GPX
>> files (per instructions here
>> http://wiki.openstreetmap.org/wiki/Recording_GPS_tracks).  However, I am
>> very new to OSM contributing and was wondering if there is a set of best
>> practices (how much is too much data, how to snip trips for privacy, etc.)
>> or if there is someone I could work with directly to ensure that the data I
>> give you is both private (for us and our clients/drivers) and useful (to
>> the community).
>>
>> Specifically, I'm interested in using these traces to identify where we
>> might be missing small connector roads or other features that could improve
>> the accuracy of routing built on OSRM.  Another potential application would
>> be to help identify areas of bad traffic or help improve speed profile
>> information - I realize this isn't something currently supported by OSM but
>> to the extent our data are useful for new or experimental features or data
>> sets I'd like to know how to help out.
>>
>> If anyone has direct experience in this area I'm open to thoughts and
>> suggestions.  Also, if anyone knows people who I should contact it would be
>> awesome if you could make an introduction.  We have a very large volume of
>> data that I hope can significantly improve the quality of OSM.
>>
>> Best,
>>
>> Jed Horne
>> Uber Technologies
>>
>> _______
>> Imports mailing list
>> Imports@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/imports
>>
>>
>
> ___
> Imports mailing list
> Imports@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/imports
>
>


-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
http://lists.openstreetmap.org/listinfo/imports

Re: [Imports] [Imports-us] Baltimore Building Outlines Import

[Elliott Plack]

Matthew emailed me last night about this, and I'm excited to see him take over. 
I hadn't thought to pull the addresses from the parcel network.


I can also confirm the data is public domain. I work closely with the city GIS 
team in my work at Baltimore County.


Matthew: since your doing addresses, perhaps I should remove some buildings I 
already brought in.


Building type: you might be able to tell if its classified residential or 
commercial or whatever from the GIS data.


Looks great overall!


Elliott
—
Elliott Plack
Sent from Mailbox on iPhone 5
about.me/elliottp

On Sat, May 4, 2013 at 12:36 PM, Clifford Snow 
wrote:

> On Fri, May 3, 2013 at 9:03 PM, Matthew Petroff
> wrote:
>>
>> Using QGIS, I assigned approximate street addresses to each building using
>> a
>> parcel map [3] and used the field calculator to clean up the labels and
>> remove
>> abbreviations. In addition, I removed all data that intersected with
>> existing
>> buildings to preserve existing work. I then separated the data into smaller
>> chunks and converted the Shapefiles to OSM with Merkaartor. After
>> simplifying
>> Merkaartor's output using osmconvert's "--drop-author" switch, I tagged the
>> data with sed, before finally using JOSM to remove duplicate vertices and
>> empty
>> tags. My only qualm with the data is that some buildings have more nodes
>> than
>> they need, but I'm not sure what can be done about it besides manually
>> reviewing
>> and simplifying all 200k+ outlines.
>>
> This is a great project. Having building outlines really helps when doing
> mapping parties.
> I would recommend doing a sample check of parcels and building outlines to
> verify that the combined data is accurate. And since you are using parcel
> data, is that also Public Domain?
> How many more nodes do typical building contain? We found importing
> building outlines in Seattle, that the imported outlines were much more
> detained, and accurate, than human drawn outlines. More nodes, but much
> richer looking outlines.
> I would recommend reading wiki.openstreetmap.org/wiki/Imports and adding
> your import to the catalog. You can use our import of buildings and
> addresses to Seattle as an example. See
> wiki.openstreetmap.org/wiki/SeattleImport
> Lastly, how do you plan to actually import the data? Are you using a
> script? If so what are you using?
> -- 
> Clifford
> OpenStreetMap: Maps with a human touch___
Imports mailing list
Imports@openstreetmap.org
http://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Proposed small import of UTA bus stops

[Elliott Plack]

Looks good. I've been pondering a similar import, but the stop location
data isn't very accurate in my jurisdiction. Many are in the middle of the
intersection, in a building, or nearby. Do you find that each stop is very
close to where the actual stop pole/sign is?


On Sun, Apr 21, 2013 at 10:54 PM, Martijn van Exel  wrote:

> Hi all,
>
> I posted the message below to talk-us and imports-us earlier, but after
> reviewing the import guidelines I thought it appropriate to also post here.
>
> It was pointed out to me that I have not followed all the suggested steps
> outlined on the import guidelines page. Let me just add that I don't intend
> to go forward with this until I have performed all the steps deemed
> appropriate for a data import. This is the first time I am attempting an
> import and I fully intend to get it right. Even if that means that the
> import won't happen.
>
> It was also pointed out to me that it is not clear under what license the
> original data is being released. While I got verbal confirmation that I can
> do 'anything I please' with this data, I will seek written confirmation
> that the data is released under terms that agree with ODbL.
>
> More feedback that I have already received:
> * is_in is considered deprecated, I will likely drop these tags.
> * Some find/replace operations were too greedy ('Salt Lake is_in:city').
> * use the modern public transport tagging scheme in addition to bus_stop.
>
> I look forward to hearing your feedback.
>
> Martijn van Exel
>
> =%<===**==**
> ===
>
>
> Hi all,
>
> During the edit-a-thon today I finally got around to working on preparing
> a relatively small import of bus stop point data for the UTA service area
> (comprising a half dozen counties along the Utah Wasatch Front). There are
> ~6450 bus stops in the data I got from my contact at UTA. This data is
> being released to the public through the Utah GIS data portal [1], but the
> data I got directly from UTA is more recent (Dec 2012).
>
> Data processing consisted of removing empty and irrelevant fields, and
> sanitizing the fields that are relevant. I kept:
> COUNTY --> is_in:county
> CITY --> is_in:city
> ACCESS --> wheelchair = yes|limited|no
> BENCH --> bench = yes|no
> LOCATIONID --> uta:stop_id
>
> I checked the existing bus stop data and there are 92 existing nodes. I
> have saved these as an OSM file and intend to manually conflate these after
> the fact. This will mean most existing bus stop nodes will be removed, I
> spot checked a dozen and so far did not find a any added value. There are a
> few non-UTA stops (Airport parking lot shuttle stops etc) that will be
> retained.
>
> The source data I received can be found here: https://www.dropbox.com/s/**
> tyxdhf9hlpuc9z8/BusStops_UTA_**shp.zip<https://www.dropbox.com/s/tyxdhf9hlpuc9z8/BusStops_UTA_shp.zip>
>
> The processed data can be found in OSM XML format here:
> https://www.dropbox.com/s/**v3c0tsgfhlc6izx/busstops_uta.**osm<https://www.dropbox.com/s/v3c0tsgfhlc6izx/busstops_uta.osm>
>
> Future updates will be handled using the persistent uta:stop_id. A new
> stops file is released around once a year.
>
> Light rail stops are captured in a separate dataset that I do not intend
> to  import, as these stops and stations are mostly already captured in
> greater detail in OSM.
>
> I am running this by all of you because I have not really done any
> external data imports before. This is a relatively small one, but I would
> like your opinion on the following:
>
> * Is this data import properly prepared?
> * If not, which steps should I revisit / add and how?
> * Do you recommend using a separate account for uploading the external
> data?
>
> Looking forward to your feedback.
> Martijn
>
> [1] 
> http://gis.utah.gov/data/sgid-**transportation/transit/<http://gis.utah.gov/data/sgid-transportation/transit/>
> --
> Martijn van Exel
>
> --
> Martijn van Exel
>
> __**_
> Imports mailing list
> Imports@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/imports<http://lists.openstreetmap.org/listinfo/imports>
>



-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
http://lists.openstreetmap.org/listinfo/imports

[Imports] Baltimore city buildings import

[Elliott Plack]

Hello group. I submitted this idea to the group 7-15-12 but never got any
response. Here it is again (copied from what I just posted in talk-us):

I've been putting this one off for a while, because of the magnitude of the
dataset. I am importing Baltimore city building footprint data one
neighborhood at a time. Running an intersect of this layer against the
neighborhood layer breaks it down into bite size chunks that are easier to
work with. I've gotten the necessary permission from the city, and talked
about it with local users at the editathon, as well as over email or in
person.

Here is the data:
https://data.baltimorecity.gov/Geographic/Building-Footprint-Shape/deus-s85f

Here is the workflow:

Open data in GIS program
Open neighborhood boundaries (same website) in same GIS program
Intersect, select single neighborhood worth of buildings
Save as individual shapefile
Launch JOSM
Bring in shapefile
Download data (as new layer)
Compare every existing feature to new ones (can take a while)
Look for traced buildings that use non-ortho imagery (shifted)
Copy any tags from existing building features to building in new dataset
(preserving others work)
Remove machine tags from new data
Tag as building=yes
Copy all multipolygons to .osm data layer
Copy all polygons to .osm data layer
Verify tagging
Check for errors
Fix duplicated node errors with JOSM
Fix building inside building errors by removing extra nodes
Final check by turning new data on/off and looking for overlaps
Upload with special EP_Import account

http://www.openstreetmap.org/user/ElliottPlack

-- 
Elliott Plack
http://about.me/elliottp
___
Imports mailing list
Imports@openstreetmap.org
http://lists.openstreetmap.org/listinfo/imports