What functionalty should be included in Version 2?

[ThomasEmge]

Let's use this issue to collect ideas about what functionality (technology choices, feature functionality, etc.) you would like to see in the next iteration of the OSM Editor or may just OSM geoprocessing tools.

[mboeringa]

• Optimize the Load OSM File code to run faster, while maintaining the ability to run with low RAM. Relevant reference: Continung the disfunction for 10.2.2.... #79
• Re-factor the XAPI download tool (code) to be more robust and user friendly, taking note of the issues and wishes detected in the references. Make it work more like the QGIS OSM download option, that automatically detects the data frame's extent and shows download progress. Relevant references: Update download_using_xapi.py #82, Update Download OSM Data XAPI Tool help text #86, XAPI tool logic for download extent (convert to decimal degrees) #87
• Review the DIFF workflow and if possible make it more performant (although this is a difficult operation by itself, other tools for this also seem to struggle keeping render databases up-to-date with OSM's main PostGreSQL edit databse). Better document how to use it and what exactly it does, maybe even graphically using professional graphics by an ESRI designer showing what a DIFF does to database records, like in the ArcGIS Help. DIFFs are a pretty difficult subject in GIS / databases in general, all the more reason to spend some time to really thoroughly document it. Also, the Start Time setting needs to be more clearly explained. After reading the documentation, and very limited testing, I still have no real idea or feel what it does or what it's exact relevancy is in the DIFF workflow (again, graphics may help also...). Relevant reference: Improve performance of DIFF files Improve performance of DIFF files #59
• Fix the remaining issue I detected with processing OSM buildings (Schloss Bellevue in Berlin type problem): Tackling OSM "Simple 3D Buildings" #72 (comment). Buildings are important, and having parts missing will be disturbing to users.
• Investigate if there is any use for the PBF file format in the ArcGIS Editor toolbox workflows (is it actually already used for DIFF support?). I am actually not to sure that the request for PBF support as in pbf support #55 will result in benefits over the current XML approaches, where applicable. Maybe it is better to first optimize the XML processing, if possible. Certainly, any PBF support should not break any existing tools or conversion results like produced by the Load OSM File tool. It should be 100% compatible. But maybe there would be some benefit of having a Load PBF File tool?? There is at least a benefit in terms of download times, as the files are smaller than zipped XML by about 40%, but this may only be relevant in areas with poor internet connections.

[mboeringa]

• Possibly switch to 256 (variable width) character fields, as per @ajturner's suggestion here: Sane defaults for OSM field widths #81 (comment) instead of 30 for the "default" fields (e.g. "highway","railway"), and 100 for other fields. This will prevent truncation of values. This will need investigation. Truncation may not be that common given current tag values, and there may be a penalty for large values of width on a variable width field, as per the link I gave here: Sane defaults for OSM field widths #81 (comment) due to row size overestimation in database query optimizers...

[mboeringa]

• Another option that struck me as missing and being nice to have: a specialized "identification" option for osm tags, that specifically extracts and displays all tags for the selected feature as present in the ESRI tag storage (special editor field osmTags). This option should therefore not show any ordinary attribute fields, but only the real tags as defined by OSM users.

This option would allow to see all tags present, instead of an arbitrary subset as represented by fields extracted by the OSM Attribute Selector.

[mboeringa]

• And another small functionality that may be desirable: a progress indicator for the "Counting elements in OSM file..." step, which is the very first step of the loading process. Currently, there is no indication whatsoever of progress. While OK for small extracts, with large extracts the "Counting elements in OSM file..." step can actually take quite some time. At the very least, if no 0-100% progress can be shown for this step due to technical limitations, at least an "activity" indicator would be nice.

[tonyemery]

It would be super cool to add overpass api requests in the load osm file (or in a new tool).
I made a python script witch import osm data in a planet file using overpass api and it works.
I can help if you want...