Recent diary entries
Facebook and ESRI announced they were adding additional data-sources into their iD fork called rapiD. They’ve collected data sources, performed schema translation, and created a conflation tool, but after being asked to follow the import process, they’ve insisted it’s not an import and they don’t need to solicit community feedback.
So here’s some feedback which they might have gotten from the community, if they had asked.
MapWithAI Data Source License
The Services Data is made available to you under the terms of the MIT license.I’m not a lawyer, but the MIT license isn’t compatible with ODbL and OSM. This could lead to all edits from rapiD needing to be reverted. Each data source license should be documented inside OSM’s wiki, with your import proposal.
You may not ... reverse-engineer any of the softwareyou forbid critical analysis of your import. Nice.
you accept any changes to the Terms by continuing to use the Services after We post the changesTruly evil!
MapWithAI Data Source Quality
- The AI generated way geometry looks good, but the
highwaytag values seem consistently wrong. The acceptable error rate for an import is debatable, I aim for > 95% accuracy in my work. It is irresponsible to even suggest low quality data. You should prompt the user to supply the
highwaytag’s value instead.
Esri Data Translation
- The design looks promising, but there is no way to evaluate its implementation without seeing the script. The resulting data is published in a way which is difficult to review since esri doesn’t offer an export. After scraping the data, I’ve found some issues which I’ve reported on each of their talk pages:
- Madison KY - minor issues
- Alaxandria VA - perfect
- Boston MA - minor issues
- Franklin OH - serious problems
- Orange County CA - moderate issues
- Richland ND - minor issues
- Riverside CA] - minor issues
- Tampa FL - minor issues
- SanDiego CA buildings - moderate issues
- more to come (I’m still doing reviews and will update this)…
Conflation Tool (rapiD)
Remove this featureonly hides it for the current user/session, and it will be re-suggested next time. You’re pushing features even after a mapper flags them as wrong. This will default to the judgement of the /least/ discerning mapper. Excluded elements need to be put on a “no-list”, and never showed again unless specifically requested, and even then, with a visual cue indicating that they have been flagged. This issue was first reported to you in January.
- You’ve decided to prevent the mapper from removing the
sourcetag. You’ve implemented this by disabling the tag’s field/button/icon, but that’s broken in two ways:
- Buildings: I am able to click the remove button on imported buildings’
sourcetags even when the field/button/icon is disabled.
- Ways: I’ve found the source field/button/icon is enabled and clickable after some combination of working with other elements and coming back. (This was tricky, let me know if you are unable to reproduce this and I can do a screen capture)
- I’d suggest removing the feature preventing users from editing/removing the
sourcetag. And removing the requirement from your license.
- Buildings: I am able to click the remove button on imported buildings’
- Each dataset offered for import need to be referenced in the change-set
sourcetag (even if that duplicates element tags).
sourcetags from your import should be documented here.
- Each changeset should include a tag linking to your import proposal. I use
osm_wiki_documentation_pagebut anything like
more_infowould be fine.
- The Oganized Editing Guidlines require the use of a hashtag in the comment.
Lack of import proposal, lack of solicited community review on the proper channels, lack of response to community feedback. Read the import guidelines. The import process is designed to govern exactly the activity that you’re engaging in, and prevent exactly the problems you’re creating.
Mapwith.ai should be taken offline until
Remove this Feature button is addressed and changeset tags are added. Then bring it back, fix your license and documentation, publish the data sets, and solicit broad community feedback through established channels. The Esri dataset should be removed from circulation until they have gone through community review. I’m worried you’ll look at the issues I point out and just fix those. That is the incorrect response. Even if you can’t accept that you’re running an import (because politics or some internal policy?) you can still follow the process designed to ensure a happy community and prosperous map.
This is just the feedback from a single person, imagine what you might get from the rest of the community. I hope that large organizations could be held to a higher standard. I’m disappointed (but not surprised).
For transparency, if you respond to this rant, please indicate if you’re an employee of FB, esri, or one of their partners, and say if your message is your personal opinion, or the opinion of your employer. If you’ve signed an NDA, blink twice.
I just finished the Maine address import and thought I might share a narrative.
In early 2019, I was driving home, getting directions from google maps. I had grown apathetic to fast food restaurants highlighted on the map, but on this trip, the google lady vomited forth: “Turn left at People’s United Bank”. She might have said “turn left on Main Street” or just “turn left” but the application I trusted for navigation went out of its way to shill a business. I was left wondering “what else does it do”. Could advertisers pay to /optimize/ my route, sending me past their venue? That sounds /crazy/, and plausible. So it was time to make a change.
The alternative I found was OsmAnd. But upon trying it, I found Maine was missing nearly all addresses. I was baffled how that could be, and dismayed that I might crawl back to google maps. This wasn’t just impeding me, this would block anyone in Maine from switching, and /I am stubborn/. I realize everyone can contribute to OSM and Maine had a handful of contributors, but at the current rate, Maine may not be navigable within my lifetime. It needed a push.
I had a vague idea of “get data from here” and “put data there”. The APIs had documentation and I had a compiler, how hard could this be? I started developing tools in July of 2019. In the beginning, I had two concerns:
- I could lose interest and leave the work “half done”, and regret that I ever started
- I could do a terrible job… and regret that I ever started
Looking back, this project held my attention the whole way and I’m satisfied with the results.
Side node: Did I look for existing tools? Yes, but I’m a software engineer and when you have a hammer everything looks like a nail.
Using my language of choice, I wrote an Osm API client, a client for Maine’s address API, a E911-to-OSM schema translator, a conflation engine, and a command line interface to tie it together.
Some effects of writing my own tools:
- Good: I am now intimately acquainted with the many challenges of each component
- Good: I had complete control and visibility into every part of the process
- Bad: I never polished the user interface, so it was only realistically usable by me. I couldn’t divide the work between other mappers
- Good: I had hoped the tools would be useful to the community. Some parts are already being used in other projects, some parts are effectively dead
- Good: I was able to contribute fixes to other, related projects
- Good: I have a substantial portfolio of work to show potential employers
With passable tools, I started processing the import in January of 2020. My tools evolved constantly throughout the import handling ever-weirder corner cases. Her are a few of the poor assumptions I made along the way:
- The source data will be accurate and clean
- The state won’t change their API and schema in the middle of my project
- Geometry is easy, simulating the human decision making process for picking things to combine is easy
- House numbers always relate to roads
- There wouldn’t be odd bunches of addresses that need to be handled specially by context (trailer parks and apartment buildings)
- There would never be ambiguity about which municipality something is in, or what a municipality is called (villages, unorganized territories, reservations, plantations)
- There won’t be many data conflicts to manually resolve (Portland took ~20 hours, Sanford took ~30 hours)
- I can use existing OSM road data to validate addresses
- I can use existing OSM municipal boundaries to validate addresses
- Names will be in canonical form (Rose Road, Roses Road, Rose’s Road, Roses’ Road, ROSES ROAD, Roses Rd, Rosesroad, Roses Street, etc)
- And many more…
I was working at a large international company, doing work that I genuinely believed in (we literally saved lives, a few a day) but the work had turned gray. I didn’t notice I was burned out until I found this project, and absolutely loved working on it. It reminded me that programming /is/ fun, and I started to realize work had /stopped/ being fun. There were many reasons, but primarily, I wasn’t learning anything new. I spoke to my manager and asked for a whole lot of unpaid time off, which was declined. So I quit (and got my unpaid time off). Aside from other interests, I spent the next year working this project. It has given me a great sense of accomplishment and contribution. I met many characters long the way and learned a lot about my state. And finally, I can use OsmAnd for navigation.
Did I mention I’m available for hire? I offer this project as my resume while I seek GIS opportunities.