Re: [Imports] Introducing OSMLY
On Thu, Sep 19, 2013 at 8:24 PM, Aaron Lidman aaronlid...@gmail.com wrote: [...] OSMLY is a simple browser based importer for OpenStreetMap. It makes importing easy by presenting each feature one at a time, allowing users to manually review the item, make any needed adjustments to positions or tags, and upload directly to OSM. It also allows for reporting problems that other users can look over and a quality assurance mode where administrative users can confirm everything that has been uploaded. The aim is to make simple imports easier, more cooperative, and less error prone. [...] This looks wonderful, thanks for developing this! This will definitely help spread the work around when it comes to simple imports. It's also got great potential to be extended to support points and lines, and even simple conflation of points. Great job. -Josh ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
Re: [Imports] TIGER realignment import
On Tue, Aug 6, 2013 at 9:10 AM, Andrew Buck andrew.r.b...@gmail.com wrote: I am not an expert on how .osc files work, but I assume they just apply to your current dataset and then show up like normal changes made manually, so the search for 'modified' should work as expected. You'd have to download data for the area covered by the OSC file, then merge the OSC and downloaded data layer together. This is tricky for large, dense areas. It would be best to download all objects within 50m or so of any changed objects. This could be done though an Overpass query I believe, so perhaps instructions could be provided to do so, along with your suggestion of using the Todo plugin. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [Talk-us] MassGIS Building Import Start
On Thu, Dec 13, 2012 at 10:58 AM, Jason Remillard remillard.ja...@gmail.com wrote: Hi, On second thought, we will ask everybody that wants to help to use their own import account. Besides the simplifications, and the re-projection verification does anybody have any other issues? Can we get some stats, as to how many structures there are, and the number of nodes, before and after any simplification procedure is run. Obviously the number actually imported will be less, since I'm assuming there are a few structures already mapped in OSM. :) From reading the MassGIS page for this dataset, they are using the roofprint of buildings, while the OSM wiki says the footprint should be used (e.g. don't include a large awning as part of the structure). Now personally most of what I map uses the roofprint, unless I can easily discern the footprint. I don't see a problem with importing the MassGIS data as is, but what should importing users do if a building already exists, but one uses footprint and the other the roofprint? Adding to this point, I think there needs to be guidance for importing users. Perhaps before launching this import, you and one or two others can import a few hundred or thousand buildings write up lessons learned, suggestions, best practices, whatever you want to call it. Both in terms of making judgment calls and in terms of the most efficient method in a given tool. For example, if there is only one POI node in the middle of a building, and you can be reasonably sure they refer to the same place, merge the node info to the way (or not, but if you do be sure to use Replace Geometry command in JOSM which I improved for just this purpose). This guide would obviously be useful to more than just the MassGIS import, but any building import. Perhaps this already exists? -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [Talk-us] MassGIS Building Import Start
On Thu, Dec 13, 2012 at 12:46 PM, Jeff Meyer j...@gwhat.org wrote: On Thu, Dec 13, 2012 at 8:55 AM, Josh Doe j...@joshdoe.com wrote: Obviously the number actually imported will be less, since I'm assuming there are a few structures already mapped in OSM. :) Should there be an implicit assumption that structures already mapped in OSM are of better quality than those being reviewed for import? Obviously, there shouldn't be a blind overwrite or duplication, but the process Jason has outlined involves a fair amount of curated review. For the first take, yes, don't import any structures that are already mapped (or really, just overlap), which is what he seems to have done with the preprocessing step. It would be useful to create a second OSM file with structures that were excluded in this preprocessing step, so a second step could be to compare them in case MassGIS is more accurate or up to date than what is in OSM. Perhaps Jason has already done this, or at least saved the original database so this can then be run. It would be very messy to determine which buildings were excluded after the import is done, without looking at the full history of each building. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Import/Bulk Edit classifications
On Fri, Oct 19, 2012 at 1:31 AM, Paul Norman penor...@mac.com wrote: [...] - I surveyed a new interchange but didn't get a usable GPS trace for all of the overpasses. I had a data source that agreed with my survey and was more complete, so I used it instead. I spent a significant amount of time making sure all the relations and tagging not in the source (e.g. bike access) was carried over. Is this an import? In this case it was CanVec so I could handle it either as an import or not, but I have other sources for other areas that are legally compatible used that haven't gone through any import consultation. I do this all the time. I know some people like to dump data into OSM unedited with an import account, and then go back and fix it up with their normal user account. This doesn't make any sense to me; why add possibly invalid data? I've always made a practice of thoroughly reviewing and editing any data in JOSM _before_ I upload it. In this case using an import account doesn't make sense to me, however I do use source=* tags on the changesets. I've mostly done this with my county's street centerline and parks database (with proper permission). -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [OSM-dev] OSM Wishlist
On Fri, Oct 19, 2012 at 12:40 AM, Paul Norman penor...@mac.com wrote: It went decently well. I stuck the raw powerpoint up at http://pnorman.dev.openstreetmap.org/ogr2osm.pptx and a PDF of the slides (no notes) at http://pnorman.dev.openstreetmap.org/ogr2osm_1.pdf If anyone can suggest a good place to post a powerpoint that deals with speakers notes in a sane manner, let me know. I have it up at http://www.slideshare.net/penorman/ogr2osm-presentation but the notes are fairly hidden and some formatting is lost. Thanks for those slides, glad to see ogr2osm is being maintained and improved. Quick question, last I worked with the tool I had to glom the ways (combine ways with identical tags) with another tool after processing with ogr2osm; does ogr2osm currently do this somewhere after filterTags()? I know my county likes to split streets at intersections to give each segment a unique ID, and the data is unusable unless it's been glommed. ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Atascadero, California building footprints import
On Wed, May 30, 2012 at 6:24 PM, j...@joelarson.com wrote: Friendly friends on the imports list, I would like to propose and discuss an import of building footprint data for Atascadero, California, USA consisting of 42,520 nodes 6,663 ways 8 relations. This data seems to be of excellent quality, and has clearly been manually reviewed. I'd suggest looking at my recent reply regarding the UVM dataset about the JOSM conflation plugin, but you seem to be aware of it since you are one of the few who have submitted bug/feature issues. :) If you used my plugin to help you review this data, great!, I'd love to know about it. If it failed miserably, great!, I'd like to know how it could be made useful. A very useful recent change I've made is to have a threshold distance, so matches won't happen between objects that are greater than that distance. I'll try and push a release this weekend. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Joining/merging address attributes to existing footprints
On Tue, Apr 24, 2012 at 3:37 PM, j...@joelarson.com wrote: Josh - thank you for reminding me about the Conflation plugin for JOSM. I've been down the whole OpenJump, RoadMatcher conflation effort when our County purchased contractor delivered street-centerlines (also public domain) - never followed through on that project/effort but I have great optimism about the JOSM Conflation effort. I will get accustomed to the plugin-workflow and give feedback, as well as follow your developments...are you funded or take donations at all for your work on this? The conflation plugin is purely a hobby of mine, which is why it's taken over a year to produce anything useful. I've recently made some changes which should make the plugin far more useful, namely in that undo/redo is now supported, you can conflate between layers, including copying unmatched objects from the reference layer to the subject layer, you can conflate multiple matches/objects at once, and a few other minor changes. Next significant change should be to allowing custom scores, as right now only distance is used. As far as donations, if anyone finds it particularly useful I'd consider accepting a dedicated GPS unit as a gift (my Android phone can be flaky at times), but I don't think I'd take any money. Feedback, bug reports, and code on the other hand are greatly desired. :) -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
[Imports] Criteria for matching objects for conflation
I'd like to get feedback on criteria typically used for conflating (merging) objects, either within the OSM database or between the OSM database and an authoritative database. The JOSM conflation plugin I've been slowly working at for a while now is starting to come together, and can be actually used, though in a limited number of cases, such as merging house number nodes with building outlines. I'd now like to create a dialog for choosing the criteria used to determine the score of a potential match between objects. The score ranges from 0 (definitely not a match) to 1 (perfect match). The current score is simply the Euclidean distance between objects. However, as I use the Java Conflation Suite and the Java Topology Suite, I have a large assortment of criteria at my disposal, such as Hausdorff distance, polygon overlap, angle histogram, string similarity, etc. All of these matchers produce a score, but they can then be combine in various ways to give a composite score. Examples include doing a weighted sum of scores, thresholding scores, etc. I'm uncertain of how to allow the user to specify the criteria to be used, as the combinations can be limitless. I was thinking of sticking to a simple weighted sum, allowing users to add any matchers they choose, assigning a weight and threshold to each one. This dialog will already be quite complicated, so I'd like to see if there's a way I could simplify things. http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation https://github.com/joshdoe/josm-conflation-plugin Thanks for any feedback, -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Joining/merging address attributes to existing footprints
On Mon, Apr 23, 2012 at 7:07 PM, Joe Larson j...@joelarson.com wrote: What I am now looking at is a workflow to join or merge attributes from an existing Address Points layer that is in Esri format(s). What I wanted to talk about here was my proposed mapping from the Esri point file to OSM attributes and also the actual workflow. Welcome, and thanks for coming to this list before you get started. The join or merge: I'm still open to workflow suggestions but I might use the ArcGIS Editor for OpenStreetMap for this process. This will require Adding/Changing Feature Properties http://esriosmeditor.codeplex.com/wikipage?title=Add%2fChange%20Feature%20PropertiesreferringTitle=Change%20OSM%20Editing%20Options so I can do a Spatial Join of Address Points that touch building-footprints and transfer their attributes to the appropriate OSM attribute parallel. I wonder if this can be done easier with ogr2osm.py and JOSM however… I don't have access to ArcGIS, so I don't know how that would work. I am working on a conflation plugin for JOSM however, and this workflow is one of the intended uses for it: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation I'm making changes to help a user conflate address nodes with buildings: http://josm.openstreetmap.de/ticket/7374 You can follow code developments here: https://github.com/joshdoe/josm-conflation-plugin/commits/master I'd appreciate feedback as I make these changes if you think it might be helpful for you. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [Talk-us] tiff, dwg and nad83
On Sun, Apr 15, 2012 at 2:37 PM, Charlotte Wolter techl...@techlady.com wrote: The exchange between Frank Cox and others about importing data is a perfect example of an ongoing problem with this list: Many of the discussions and answers are simply too GIS geeky for the vast majority of us. I'm not entirely sure this is helping to address your concerns, but I just created a checklist for importing which should help: http://wiki.openstreetmap.org/wiki/Import/Guidelines#A_checklist The goal is to provide a quick overview of the steps in importing data. This can certainly be expanded, so please do so. Replies should probably go to the imports@ list rather than talk-us@, since it's not talk-us@ specific. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] ogr2osm: How to deal with multilinestrings?
On Tue, Mar 27, 2012 at 10:28 AM, Andrew Guertin andrew.guer...@uvm.edu wrote: My question, then, is whether this is normal. Do other files have multilinestrings like this, and would benefit from changing the default handling--or is this file just poorly made, and should be fixed in file-specific translation routines? Conversely, do other files have multilinestrings that should be turned into relations, and would be harmed by changing the default handling? The vast majority of the time, using the current tagging standards, MultiLineStrings shouldn't be converted to relations, and we should use Paul's approach. The only widespread exception could be type=route, but even then I doubt this would be helpful for mapping data that is to be imported/conflated with OSM since we still tag member ways (and even though some data is overlapped between the relation and the way, the concepts are different). Perhaps in the future our tools and model will improve to support this kind of structure, but we're not there now. Definitely make it possible to create relations from MultiLineStrings, but by default apply tags to member ways. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [Talk-us] Uploads to City of Salisbury, MD
On Thu, Mar 22, 2012 at 6:40 AM, Josh Doe j...@joshdoe.com wrote: On Wed, Mar 21, 2012 at 10:50 PM, Paul Norman penor...@mac.com wrote: If there are duplicated ways and nodes, perhaps reverting is the best option? Unfortunately I'd agree that reverting these changesets will be the easiest and best course of action. Trust me that you'll spend a long time cleaning up dupe nodes and ways. Some of the buildings have up to four dupe nodes and 3 dupe ways, all from different changesets. This is what I can tell from the first few building changesets (not an extensive investigation): 10882159: 493 dangling nodes (REVERT) 10884039: 3517 dangling nodes (REVERT) 10885267: 1 building node (OK) 10891857: 5 dangling nodes (REVERT) 10891870: 8000 dangling nodes (REVERT) 10893364: building nodes and ways (OK?) -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [Talk-us] Uploads to City of Salisbury, MD
On Thu, Mar 22, 2012 at 8:04 AM, Marc Zoss marcz...@gmail.com wrote: I briefly downloaded all sby:bldgtype-tagged ways and relation of Maryland through the overpass-api. Then removed the ones having only a sby:bldgtype tag, run the validator and deleted the duplicated nodes and ways. This would result in a changeset to remove the roughly 71'000 duplicates nodes and ways. If the area was edited since the import and reverting gets tricky, this might be the option to go, at least the result looks ok at the first glance. Please also note that the conversion step seems to add a building=yes tag on on inner ring of building polygons () which is certainly bad tagging, despite the correct rendering (52 occurrences, so could be fixed manually). Thanks for doing that, as that was the next step I was going to try. I posted some regarding the changesets here: http://wiki.openstreetmap.org/wiki/User_talk:Nick_SPW#Salisbury.2C_Maryland_import I think perhaps we should revert a subset of the changesets, such as the dangling nodes, and then use your method to handle the rest. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [Talk-us] Uploads to City of Salisbury, MD
On Thu, Mar 22, 2012 at 10:52 AM, Nick Chamberlain nchamberl...@ci.salisbury.md.us wrote: Mark, if you could commit the remove duplicates changeset, that'd be great. I will do my best to check if the issues are resolved, and will gladly accept any guidance on the best ways to do so. Thanks. I'm reverting a few of the changesets as we speak, so if Mark could hold off a few minutes, I'll update you all as I go. Since this only concerns the US, future messages will only be sent on the talk-us@ list. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Landsat forest classification
On Thu, Mar 8, 2012 at 8:25 AM, Dimo Dimchev reac...@abv.bg wrote: I see many countries using the CLC and the results are good looking maps at lower zoom levels. When I zoom in, there are no more details and some data seems to be incorrect. I tried to make classification of a landsat scene and the results I got look promising. New imagery allowed new changes to reflect on the map and much more details were on the map, giving the bigger data size. I'm not particularly a fan of importing this kind of data unless it is carefully inspected. I'm becoming more and more convinced that land cover information should belong in a separate database, since it doesn't have any topological relationship to any other data. I have some examples over the south-west of Sofia http://img43.imageshack.us/img43/431/imagerym.jpg and a test changeset over the eastern Rhodopes http://www.openstreetmap.org/?lat=41.6761lon=25.9656zoom=12layers=M The main OSM database is not a place for this kind of test import, especially considering you named the forests as test data. The Bing imagery isn't of sufficient resolution to tell how good this data is, but I see that many (all?) of the ways are duplicated four times, only one of which belongs to the multipolygon. I would highly recommend that you revert this changeset until further discussions occur on this list and with any relevant local mailing lists or groups. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] A few questions about importing U.S. NHD data for Subbasin 01080105 import (White River in VT)
On Thu, Feb 23, 2012 at 4:15 AM, Alan Mintz alan_mintz+...@earthlink.net wrote: This is one of the things I dislike about the NHD imports that I've seen - the vast number of short segments that creates such feature density as to make any manipulation (download, editing, etc.) of the area more difficult. These short segments should be joined before import. +1, definitely combine these before import. Some call this process glomming. I've got an ugly C# app that I call OsmGlommer that I hacked on based on code from MikeN, but I haven't put it online yet . You can also try Frederik's merge-ways.pl [0]. -Josh [0]: http://trac.openstreetmap.org/browser/applications/utils/filter/merge-ways/merge-ways.pl ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] US Golf Courses from GNIS
I just pulled in the changeset, and only three nodes have been changed: Name corrected: http://www.openstreetmap.org/browse/node/1556624529/history Position moved: http://www.openstreetmap.org/browse/node/1556638779/history And deleted: http://www.openstreetmap.org/browse/node/1556629698/history I'd suggest this be reverted tonight, keeping the two corrected nodes. Also, when we re-import this (more slowly), I don't think we need any of the gnis tags except for the ID, which should probably use gnis:feature_id. If I get a chance and no objections, I'll revert this tonight (~8 hours from now). -Josh On Thu, Dec 22, 2011 at 1:59 PM, Josh Doe j...@joshdoe.com wrote: I've noticed in my area golf course nodes added that already exist: http://www.openstreetmap.org/browse/node/1556625188 http://www.openstreetmap.org/browse/node/1556629688 and others I support reverting this changeset ASAP. Golf Geek, Let's instead take the work you've done and split it up into state sized chunks (e.g. via Osmosis). Then several contributors including yourself can manually merge the nodes a state at a time. Thank you for your interest in this, and for coming forward on the mailing list. Trust me that this is not the first time this kind of thing has happened, but you did the right thing coming here and letting us know. Regards, -Josh On Thu, Dec 22, 2011 at 2:03 AM, Toby Murray toby.mur...@gmail.com wrote: More problems I found by just downloading all leisure=golf_course objects and randomly browsing around some of Kansas/Nebraska with Bing imagery. Can't idenfity on aerial. I could just be missing it. Or GNIS position might be off by a lot. Some are in the middle of a town without so much as a full block of grass anywhere near them. Or it may have been closed but is still in GNIS. It is unlikely that it is a new golf course. Bing imagery seems to be pretty recent (2010) in most areas I looked at. http://www.openstreetmap.org/browse/node/1556624422 http://www.openstreetmap.org/browse/node/1556638495 http://www.openstreetmap.org/browse/node/1556635779 http://www.openstreetmap.org/browse/node/1556635714 http://www.openstreetmap.org/browse/node/1556624015 http://www.openstreetmap.org/browse/node/1556625367 http://www.openstreetmap.org/browse/node/1556625957 http://www.openstreetmap.org/browse/node/1556631507 http://www.openstreetmap.org/browse/node/1556638863 Two golf courses in close proximity that are probably the same course, maybe known by two different names: http://www.openstreetmap.org/browse/node/1556638410 http://www.openstreetmap.org/browse/node/1556627728 and http://www.openstreetmap.org/browse/node/1556624801 http://www.openstreetmap.org/browse/node/1556639241 Were these not in GNIS or were they excluded because of an existing way? Could have maybe used GNIS data to add a name to the existing way: http://www.openstreetmap.org/browse/way/46342164 http://www.openstreetmap.org/browse/way/43332671 http://www.openstreetmap.org/browse/way/42280171 http://www.openstreetmap.org/browse/way/98180901 http://www.openstreetmap.org/browse/way/129025203 http://www.openstreetmap.org/browse/way/126614718 Toby On Wed, Dec 21, 2011 at 11:27 PM, Toby Murray toby.mur...@gmail.com wrote: On Wed, Dec 21, 2011 at 4:05 PM, Golf Geek golfgeek2...@hotmail.com wrote: After reviewing the Import/Guidelines wiki, I realize I should have posted here first, but here's a quick after action report on a recent import. Better late than never. :) Why didn't you read this before the import? This should not be viewed as optional. I noticed that although USGS GNIS data had been imported into OSM in the past, the US golf course locations provided as GNIS Locales had not been included. So, I retrieved GNIS Locales with Golf in the name from http://geonames.usgs.gov/ and saved them as OSM nodes, using these tags: gnis:Class = Locale gnis:County = [various] gnis:ST_alpha = [various] gnis:id = [various] leisure = golf_course name = [various] source = USGS GNIS From the list of ~6000 nodes, I removed any that overlapped with existing OSM golf_course nodes or ways. You apparently failed to take into account how terrible GNIS spatial accuracy can actually be: Your node: http://www.openstreetmap.org/browse/node/1556636801 Existing way: http://www.openstreetmap.org/browse/way/70764331 Yes, that over a mile off. This is why the import guidelines say to discuss it with the community FIRST. There is much collected knowledge about imports in the community which can prevent such common mistakes. The remaining 4421 nodes were then added as Changeset 10168800. The data license is OK (USGS GNIS has been used before), and the new nodes should not screw up existing data (although I am sure they are not perfect), so hopefully this import will be a good starting point for further manual edits. With nodes that are off by a mile, I am doubtful of this claim. So far, I
Re: [Imports] US Golf Courses from GNIS
Revert is done, see changeset #10184494: http://www.openstreetmap.org/browse/changeset/10184494 For the two nodes that someone edited I went ahead and made them areas from Bing and added website and other detail I could glean. Golf Geek, if you'd like help I'd be happy to split your original file into state-sized chunks. I'll volunteer to merge all of Virginia's golf courses. Also, I'd be interested to know your method for reducing the ~6000 nodes to ~4000 (i.e. perhaps provide the script you used). -Josh On Thu, Dec 22, 2011 at 2:45 PM, Josh Doe j...@joshdoe.com wrote: I just pulled in the changeset, and only three nodes have been changed: Name corrected: http://www.openstreetmap.org/browse/node/1556624529/history Position moved: http://www.openstreetmap.org/browse/node/1556638779/history And deleted: http://www.openstreetmap.org/browse/node/1556629698/history I'd suggest this be reverted tonight, keeping the two corrected nodes. Also, when we re-import this (more slowly), I don't think we need any of the gnis tags except for the ID, which should probably use gnis:feature_id. If I get a chance and no objections, I'll revert this tonight (~8 hours from now). -Josh On Thu, Dec 22, 2011 at 1:59 PM, Josh Doe j...@joshdoe.com wrote: I've noticed in my area golf course nodes added that already exist: http://www.openstreetmap.org/browse/node/1556625188 http://www.openstreetmap.org/browse/node/1556629688 and others I support reverting this changeset ASAP. Golf Geek, Let's instead take the work you've done and split it up into state sized chunks (e.g. via Osmosis). Then several contributors including yourself can manually merge the nodes a state at a time. Thank you for your interest in this, and for coming forward on the mailing list. Trust me that this is not the first time this kind of thing has happened, but you did the right thing coming here and letting us know. Regards, -Josh On Thu, Dec 22, 2011 at 2:03 AM, Toby Murray toby.mur...@gmail.com wrote: More problems I found by just downloading all leisure=golf_course objects and randomly browsing around some of Kansas/Nebraska with Bing imagery. Can't idenfity on aerial. I could just be missing it. Or GNIS position might be off by a lot. Some are in the middle of a town without so much as a full block of grass anywhere near them. Or it may have been closed but is still in GNIS. It is unlikely that it is a new golf course. Bing imagery seems to be pretty recent (2010) in most areas I looked at. http://www.openstreetmap.org/browse/node/1556624422 http://www.openstreetmap.org/browse/node/1556638495 http://www.openstreetmap.org/browse/node/1556635779 http://www.openstreetmap.org/browse/node/1556635714 http://www.openstreetmap.org/browse/node/1556624015 http://www.openstreetmap.org/browse/node/1556625367 http://www.openstreetmap.org/browse/node/1556625957 http://www.openstreetmap.org/browse/node/1556631507 http://www.openstreetmap.org/browse/node/1556638863 Two golf courses in close proximity that are probably the same course, maybe known by two different names: http://www.openstreetmap.org/browse/node/1556638410 http://www.openstreetmap.org/browse/node/1556627728 and http://www.openstreetmap.org/browse/node/1556624801 http://www.openstreetmap.org/browse/node/1556639241 Were these not in GNIS or were they excluded because of an existing way? Could have maybe used GNIS data to add a name to the existing way: http://www.openstreetmap.org/browse/way/46342164 http://www.openstreetmap.org/browse/way/43332671 http://www.openstreetmap.org/browse/way/42280171 http://www.openstreetmap.org/browse/way/98180901 http://www.openstreetmap.org/browse/way/129025203 http://www.openstreetmap.org/browse/way/126614718 Toby On Wed, Dec 21, 2011 at 11:27 PM, Toby Murray toby.mur...@gmail.com wrote: On Wed, Dec 21, 2011 at 4:05 PM, Golf Geek golfgeek2...@hotmail.com wrote: After reviewing the Import/Guidelines wiki, I realize I should have posted here first, but here's a quick after action report on a recent import. Better late than never. :) Why didn't you read this before the import? This should not be viewed as optional. I noticed that although USGS GNIS data had been imported into OSM in the past, the US golf course locations provided as GNIS Locales had not been included. So, I retrieved GNIS Locales with Golf in the name from http://geonames.usgs.gov/ and saved them as OSM nodes, using these tags: gnis:Class = Locale gnis:County = [various] gnis:ST_alpha = [various] gnis:id = [various] leisure = golf_course name = [various] source = USGS GNIS From the list of ~6000 nodes, I removed any that overlapped with existing OSM golf_course nodes or ways. You apparently failed to take into account how terrible GNIS spatial accuracy can actually be: Your node: http://www.openstreetmap.org/browse/node/1556636801 Existing way: http://www.openstreetmap.org/browse/way/70764331
Re: [Imports] Converting Fairfax County, Virginia government Shapefile of streets to OSM
On Tue, Dec 6, 2011 at 7:10 AM, Mike N nice...@att.net wrote: On 12/6/2011 6:56 AM, Josh Doe wrote: Do you (or anyone else) think there's value in doing the simplifying during the conversion? And if so, to what distance tolerance? It depends on the number of data points created by the export. If there are too many data points, it complicates future edits that adjust geometry. I normally use 1 meter simplify when bringing in TIGER data, but finer would still be a huge reduction in points for some cases. Thanks, I think I'll suggest anyone that helps out with this to simplify the ways themselves in JOSM using 0.5 to 1 meter. I've got the converted OSM file in pretty good shape now, and have split it into 138 files based on elementary school attendance boundaries: http://joshd.dev.openstreetmap.org/fairfax_county/streets/by_elementary_school/ I wasn't sure of the best way to split this into manageable chunks that individuals (or perhaps just myself) can go through one at a time to make sure OSM has all the streets and important attributes. Of course we could also find errors in the government data, though the chances of that are somewhat low considering this same data is used for emergency services (at least topology and names, maybe not speed limits). I'd appreciate it if I could have some feedback on the conversion, or if there's a better way to split the file (tiles?). Thanks, -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Converting Fairfax County, Virginia government Shapefile of streets to OSM
On Sun, Dec 4, 2011 at 7:32 PM, Paul Norman penor...@mac.com wrote: From: Josh Doe [mailto:j...@joshdoe.com] Subject: [Imports] Converting Fairfax County, Virginia government Shapefile of streets to OSM I just recently noticed that Fairfax County, VA added the street centerline data to their website, and it is fairly recent (2011/10/17). I had previously gotten permission to use this data from FCDOT, but it was in ESRI GeoDatabase format and wasn't publicly accessible. Also they've added better attribution (differentiating Interstate highways from primary roads, marking highway links, etc.). I've converted the data to OSM as best I can (e.g. expanding street suffixes) but I would appreciate others reviewing it: http://wiki.openstreetmap.org/wiki/Fairfax_County,_Virginia/Roads The table on the wiki is a rough mapping, for details the ogr2osm translation script is provided further down the page. As mentioned on the wiki page, this is not for mass import but for adding new subdivisions in JOSM, replacing bad TIGER data, manual conflation with Potlatch2 [1], etc. You can either download the data yourself and run the translation script, or download this extract of the converted data: http://dl.dropbox.com/u/23634456/osm/braddock_streets.zip (ZIP of .osm file) I had a look at the conversion (based on the wiki page) and the only issue I saw was some 1 mph roads which are likely issues in the source data. Ah, thanks for picking up on this. I've added a fixme warning if the speed limit is less than 5 mph. Some of the ways are over-noded and there's the continual problem of trying to distinguish between highway=residential and highway=unclassified. I generally use residential as the default value. Do you (or anyone else) think there's value in doing the simplifying during the conversion? And if so, to what distance tolerance? For roads I don't like to use anything bigger than 1 meter. I have bright hopes and dreams of getting this data into a micro-tasking app, so I'd like this data to be as ready to merge or conflate as possible, via JOSM or the new/upcoming Potlatch2 functionality. As for residential vs unclassified, I chose the latter because I've heard chatter about the TIGER import making a bad decision by using the former. You'll also have to dis-entangle roads below bridges from the bridges, but that's fairly normal. Thanks for this one as well. I guess there's no foolproof way to automatically fix this, but perhaps there's some intelligent flagging I could do. Any suggestions? -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Acadia National Park
I've uploaded the trail shapefile to GeoCommons: http://geocommons.com/maps/108641 (trails over OSM map) geocommons.com/overlays/166479 (just the trail dataset) Kerry, Could you please share with us your converted and cleaned up version as a OSM.XML file? Could you also share your attribute to tag mapping (and your ogr2osm or shp-to-osm conversion file if available)? I'd like to know how you plan to handle the ref=* key, whether to use just the trail number or trail+section number. Here's my stab at a conversion: TRAILTYPE: Existing/Maintained, Existing/Old Fire Road - Irrelevant for OSM, both are maintained just different TRAILNAME: map to name=* ALTTRLNAME: map to alt_name=* NUM_SEC: map to ref=* MapCOLOR: map to colour=* using below table (given as HSV, but must use RGB) Anemone Violet, 284-100-90, #A800E6 Seville Orange, 40-100-90, #E69900 Lapis Lazuli, 216-100-90, #005CE6 Leaf Green, 100-100-66, #38A800 Poinsetta Red, 0-100-90, #E6 And of course you're more familiar with the park, but maybe use: highway=path foot=yes bicycle=yes operator=United States National Park Service -Josh On Sun, Oct 16, 2011 at 5:05 PM, Kerry Gallivan kerry_galli...@yahoo.com wrote: Thanks, Greg, et al, for the feedback. The data is located on the NPS data store at the following URL: https://irma.nps.gov/App/Reference/Profile/2169900 I imported the data into Merkaator to view and clean it up with labeling, etc. I'm quite familiar with the park (develop mobile apps for national parks - www.chimani.com) and the trails would complete the entire trail network. Currently there are only about 15% of trail coverage which has been traced by individual users. Thoughts? Kerry - Original Message - From: Greg Troxel g...@ir.bbn.com To: Kerry Gallivan kerry_galli...@yahoo.com Cc: imports@openstreetmap.org Sent: Saturday, October 15, 2011 7:45 AM Subject: Re: [Imports] Acadia National Park The National Park Service has recently released updated GPS trail data (public domain, for Acadia National Park (Maine, USA). Currently there is a tremendous gap in trail data for the park. This would be a reliable bulk import of data which would server as an excellent base for future user-based data to be build upon. What that are other people's thoughts on this import? Is there really so much data that it has to be treated as bulk import? Can you for example get it into OSM format and edit the area in josm and sanity-check/quality-control it, verify it doesn't conflict, etc? If so, you're not really in import land and are in a space with fewer perils. From a quick glance at the map, there is some existing data. ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] illegal import in avalon area ?
On Wed, Sep 21, 2011 at 11:02 AM, Steven Le Roux ste...@le-roux.info wrote: [snip] http://sautter.com/map/?zoom=13lat=46.96234lon=-53.07816layers=B00T is clearly showing that the source is the same than google's one, or is google itself. I'm not sure about the origin of the data, but just because it matches Google does not mean the data was taken from Google. Google and OSM very likely use some of the same source databases, such as NHD for water features in the US, government administrative boundaries, park polygons provided by localities, etc. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] ogr2osm problems
On Mon, Aug 29, 2011 at 6:09 AM, Fredy Rivera fredyriv...@gmail.com wrote: Hello We are in the process of importing data to the Ministry of Transport of Colombia will contribute to OSM, this is good news but when converting files with ogr2osm get the following error: Any ideas? Humano [snip] Simplifying line segments Traceback (most recent call last): File ogr2osm/ogr2osm.py, line 658, in module for nodeID in segmentNodes[segmentID]: KeyError: -437711 Sounds like it might be the same as this bug report: http://trac.openstreetmap.org/ticket/3512 I think it might be due to corrupt or badly-formed data, but I'm not the one that wrote that code, so I can't provide much insight. I did take a quick look at it, but didn't see an obvious problem. Maybe Ivan, the original author, can suggest some possibilities? -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Bus data for Fairfax Connector, Fairfax County, Virginia, USA
I've finally gotten back to this data, and have created a translation for ogr2osm, and have reviewed bits of the data and am pleased with the quality both in terms of spatial accuracy and attribute data. You can find the original data, translation file, and resulting osm.xml file and more details on the wiki: http://wiki.openstreetmap.org/wiki/Fairfax_Connector#Importing There are still a few kinks with the tags, so please take a look at the data and the translation file, and send me your feedback. Namely: * how to translate name (since no 'name' attribute exists, as bus stops don't have specific names, rather are described by cross streets) * should I consider overhead lighting 100 feet away as lit=yes? * should I explicitly set lit/wheelchair/shelter/bench=no in certain cases? Thanks, -Josh On Sat, Apr 16, 2011 at 1:20 AM, Josh Doe j...@joshdoe.com wrote: I've just gotten permission to use data for the Fairfax County, Virginia, USA bus system, called the Fairfax Connector. There are over 4,000 bus stops and 65 routes, though this is not counting the WMATA bus routes which visit many of the same stops. I've created a page on the wiki for this data: http://wiki.openstreetmap.org/wiki/Fairfax_Connector There is a wealth of information in this data, with 130 fields per bus stop, including details like the presence of a shelter, bench, lighting, trash can, etc. Many of these fields have no relevance to OSM, which is something I'm working through. If you're interested visit the wiki page to see a list of the fields and the top five occurring values. I'd appreciate any feedback and/or participation. And don't worry, I'm not going to perform a massive import without notice. Most likely we'd merge data manually for the 200 bus stops already present in the county, then import the rest once a field mapping is decided upon. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Proposal for proper OSM import solution (OpenMetaMap)
On Thu, Aug 18, 2011 at 6:23 AM, Jaak Laineste j...@nutiteq.com wrote: Core of the idea is to avoid external data imports and reserve OSM database for what was meant for: community-sourced (manual) mapping. I don't intend to turn this into a debate, but please keep in mind that there are differences of opinion as to what OSM was meant for, as acceptability of imports varies by region. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Mass Bus Data
I'd wait until someone more knowledgeable than I responds, but I'd say to revert those two changesets, then before uploading again split the 8000+ node file into maybe four parts. It would help if you shared a link to the relevant changesets, and it would be super if you could share the OSM.XML file you're trying to upload, so others can take a look at it and see if there are any problems. Thanks for keeping communication open. Even some of the most seasoned OSM contributors have had problems like this, the important thing is to communicate and follow up. -Josh On Mon, Aug 15, 2011 at 10:43 AM, Metcalf, Calvin (DOT) calvin.metc...@state.ma.us wrote: ** So I went to upload/merge the bus data, and everything went fine, except for where JOSM ran out of ram and crashed twice. and now after I'm done It seems I uploaded all the nodes twice.How do I fix this with out making it worse. -- *From:* Josh Doe [mailto:j...@joshdoe.com] *Sent:* Friday, August 12, 2011 7:08 PM *To:* Serge Wroclawski *Cc:* imports@openstreetmap.org *Subject:* Re: [Imports] Mass Bus Data On Fri, Aug 12, 2011 at 5:02 PM, Serge Wroclawski emac...@gmail.comwrote: Josh, Is your code anywhere folks like me can help work on it? You mean for the JOSM conflation plugin? It's linked on the wiki, and in OSM SVN: http://wiki.openstreetmap.org/wiki/Conflation/Nodes http://trac.openstreetmap.org/browser/applications/editors/josm/plugins/conflation Be warned that it needs a lot of work, but it at least draws lines between matched objects, and the cost/weight function can be improved easily. Most work lies in adapting the conflict resolution dialog to work, or creating a new dialog, perhaps something like the following but with left/right arrows for choosing values: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/TextTransform#Changing_key_name I'd be glad to get help on this. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Mass Bus Data
Since it's not likely I'll finish the conflation plugin any time soon, I'd just manually merge the nodes. If you check the MassDOT talk page I show how you can pretty quickly manually merge the nodes (123 by my count). Remember the second node you select will determine the location of the merged node. Also, you may want to remove the attribution/source tags of the OSM data, as they're all old MassGIS info anyways, that will speed up the merge process. http://wiki.openstreetmap.org/wiki/Talk:MassDOT#Merging_with_existing_data If you can't get to it, I'm sure I could do it this weekend. By the way, the quality of the MBTA data seems of higher quality than the OSM data, at least spatially speaking. Thanks for being so involved! -Josh On Fri, Aug 12, 2011 at 1:59 PM, Metcalf, Calvin (DOT) calvin.metc...@state.ma.us wrote: ** I created a wiki page explaining the tags here http://wiki.openstreetmap.org/wiki/MassDOT http://wiki.openstreetmap.org/wiki/MassDOT On second look it seems that very few of the current train stations (less then 20) have additional data that it would make sense to keep the other ones seem to have either no attributes beyond massgis import and highway=bus_stop, or have a bus route reference in in one of many different ways. The file I made is here http://dl.dropbox.com/u/37626989/mbtabus.osm.zip where do folks suggest I go from here? -- *From:* joshthephysic...@gmail.com [mailto:joshthephysic...@gmail.com] *On Behalf Of *Josh Doe *Sent:* Friday, August 12, 2011 1:22 PM *To:* Metcalf, Calvin *Subject:* Re: [Imports] Mass Bus Data Oh and another reason to have others look at the data before uploading is to make sure the tags are correct, no incorrect mappings, etc. Many eyes help to catch this sort of thing. Thanks for being involved! -Josh On Fri, Aug 12, 2011 at 1:20 PM, Josh Doe j...@joshdoe.com wrote: On Fri, Aug 12, 2011 at 1:03 PM, Metcalf, Calvin (DOT) calvin.metc...@state.ma.us wrote: ** I'm getting ready to upload the bus data. It seems some people already started putting in some bus data (there are 109 that look to overlap my data), is there a way to update/delete these/make them invisible? While some of them look to just be out dated dumps from massgis others look to have work put in. (for reference there are 8057 stops that I'm about to upload) By upload do you mean to the OSM database or to a file host for other OSM contributors to download and merge? Hopefully it's the latter, so that the OSM community can look at the data, the tags, etc and can help with the process. We certainly don't want to just delete the existing 109 stops, but rather update them with the new tags/position (if appropriate). While somewhat tedious, merging 109 stops (with JOSM's merge command) won't take too terribly long, and is a crucial step to take. If you don't wish to do this step, then consider uploading the data for others to use. I started a conflation plugin for JOSM [0] intended exactly for this purpose, for my county's bus data (~4000). The algorithm works quite well, but I got stalled when designing the user interface for reconciling differences. I'd like to finish it but like Ian said, I've been too busy in real life to continue at the moment. -Josh [0]: http://wiki.openstreetmap.org/wiki/Conflation/Nodes ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Mass Bus Data
On Fri, Aug 12, 2011 at 5:02 PM, Serge Wroclawski emac...@gmail.com wrote: Josh, Is your code anywhere folks like me can help work on it? You mean for the JOSM conflation plugin? It's linked on the wiki, and in OSM SVN: http://wiki.openstreetmap.org/wiki/Conflation/Nodes http://trac.openstreetmap.org/browser/applications/editors/josm/plugins/conflation Be warned that it needs a lot of work, but it at least draws lines between matched objects, and the cost/weight function can be improved easily. Most work lies in adapting the conflict resolution dialog to work, or creating a new dialog, perhaps something like the following but with left/right arrows for choosing values: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/TextTransform#Changing_key_name I'd be glad to get help on this. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Massachusetts road data
On Thu, Aug 11, 2011 at 9:37 AM, Metcalf, Calvin (DOT) calvin.metc...@state.ma.us wrote: ** Yeah so I guess I'll start a wiki page with some links to data that is already up there, and start slowly adding in some data that isn't, besides bus stops, there is also a traffic light layer we're in the process of finishing up. Very cool, glad to see you're doing this! Hopefully more local/state governments will follow suit. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Fwd: [OpenStreetMap] Uploading filling stations
Original-Nachricht Datum: Thu, 19 May 2011 10:57:12 +0100 Von: MOL Group service stations m-186888-5f7...@messages.openstreetmap.org An: lulu-...@gmx.de Betreff: [OpenStreetMap] Uploading filling stations About the method of uploading: Considering the magnitude of data, I would really prefer some batch upload methodology. To find the easiest way I have made some research and found a peer who already managed such uploading task in case of electric charging stations: http://www.openstreetmap.org/user/eladestationen This community member, named “eladestationen” will send a monthly set of data on electric charging station POI-s to OSM for uploading. I am asking the responsible person if I could go by the same procedure, i.e.: I send the coordinates, with company names, icons, etc to OSM who uploads them to the map. In order to continuously maintain the actual status of our filling station network we can send updates of closed or newly opened filling stations monthly or quarterly. Anyone who's interested in helping upload this data, please look here: http://wiki.openstreetmap.org/wiki/Conflation/Nodes The JOSM plugin isn't usable yet, but once it is this is a perfect use case for matching and merging their data with OSM. I've yet to have any interest in the plugin, so if anyone sees value in it let me know. :) -Josh ___ 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)?
On Mon, Apr 25, 2011 at 3:29 PM, Serge Wroclawski emac...@gmail.com wrote: I agree with Fredrik, at least in that I think humans should be the central driving force in OSM. I'm not against all imports, but nearly all. +1 about humans being the central driving force. Right now I'm working on two imports in Fairfax County (bus and road data), a place I live, work, and play in. I'm personally invested in the area, and have a strong desire to see a better map in the area. Since there are many areas in the county that I've mapped already, I am keenly aware of not squashing but rather preserving community edits. I can agree that if you don't have a similar connection to the area where you're importing data, you have no business doing so. -Josh ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [Talk-us] Importing Virginia road centerlines
I absolutely agree about preserving user contributions. For any given segment in the Virginia RCL Shapefile, there are any number of ways in OSM that make up that segment, with varying attributes. The reverse is possible as well. Merging this won't be easy by any means. However there's no reason we couldn't start importing (sooner) in areas that haven't been edited since the TIGER import As for RoadMatcher, though I haven't played with it yet, I don't see how OSM attributes are lost, it's just that you have to map from OSM-Shapefile-OSM. Remember, I'm just broadcasting my interest, I have a lot of learning to do. Regards, -Josh On Mon, Feb 21, 2011 at 12:01 PM, Mike N nice...@att.net wrote: 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. ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
