Re: [Talk-us] Tags to use for chain stores in the United States

2013-12-11 Thread Aaron Lidman
Hey guys,  

I‘ve tried to solve a mostly related problem in iD last month. I just blogged 
about it here: https://www.mapbox.com/blog/common-names-in-id/

You can try it out in iD here: http://openstreetmap.us/iD/master
Just add geometry, and search for a really common name, like K-Mart, McDonalds, 
etc.. iD should take care of it for you, using the most used tagging already in 
OSM.


For more detail. I made the name-suggestion-index: 
https://github.com/osmlab/name-suggestion-index which looks at which names/tag 
combinations are used most often and tries to promote the most used usage of a 
name. This stuff is more concerned about names, but we’re also merging together 
different tagging for features. So a place like Subway is used in both 
amenity=restaurant and amenity=fast_food, we’re looking at the most common 
usage and ignoring anything else. The ‘most correct’ list of names and tagging 
is here: 
https://github.com/osmlab/name-suggestion-index/blob/master/name-suggestions.json

It’s not great right now but I’m still working on improving it to make iD 
smarter, and maybe it can be used elsewhere too. It’s mostly a manual process 
that I’ve been doing for now but I hope to automate it more, and update it with 
every planet update. Right now we’re only concerned with places with names that 
have been used more than 50 times, also mostly amenity=* and shop=* tags right 
now.

We had some previous discussions along these lines here:
https://lists.openstreetmap.org/pipermail/dev/2013-November/027519.html
https://github.com/systemed/iD/issues/1949
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] [Imports] Introducing OSMLY

2013-09-20 Thread Aaron Lidman

Hi Serge,

Yup I've been keeping an eye on the Maproulette rewrite, I was just 
working on this before you guys started. We'll see, maybe I can help out 
somewhere.


Your concern:
In no way do I want to change the proposal or approval process for 
imports, those are in place for good reason and I will totally work 
within them. This is simply another tool, like JOSM or any of the import 
scripts, for completing those imports that have been approved and 
discussed. If there was some official means to parse a list of active 
approved imports that have been sanctioned by the DWG, I would love to 
force OSMLY to only allow those imports on the live OSM server.


On 9/20/13 5:08 AM, Serge Wroclawski wrote:

Aaron,

I have a number of thoughts about your tool.

First, the good:

This is great. It is very similar to the work Martijn and I have done
with MapRoulette. MapRoulette can essentially do what this tool does,
so there wasn't really a need for yet another tool. In fact, my only
complaint is that I wish you had decided to help us work on
MapRoulette and include more features, rather than go off and make yet
another tool in a very fragmented community. Nonetheless, this is very
nice.

The concern:

My concern is less about the tool than the technique. Just because a
user has a tool to assist them does not mean that the import can
bypass the normal community process. While this isn't directly related
to the software (and we never want to blame tools for how they're
used), I still worry about imports happening without due diligence.


Overall, I'm glad this exists, though I'd be much happier if you
helped us with MR, which can do this and more. :)

- Serge





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


[Talk-us] Introducing OSMLY

2013-09-19 Thread Aaron Lidman
The following post is best viewed at http://osmly.com (http://osmly.com/) full 
text is posted below for posterity.



 

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. 

http://osmly.com/screenshots/example.jpg 

Try the demo: http://osmly.com/la-parks.html 

OSMLY was born out of a frustration with the way imports are organized. I was 
preparing some imports for Los Angeles County, reading up on past imports and 
organized things according to how I see they are being done today (wiki, 
spreadsheets, many .osm files, JOSM). I wasn't into it. The organization and 
tools involved seems too complicated and clunky for getting more than a small 
number of people involved. 

Even with very simple data we would have to deal with many .osm files each 
containing many features themselves, a central spreadsheet for tracking who is 
doing what and the status of each group of items, and everyone would have to 
use JOSM. Then editing involves managing multiple layers in JOSM, downloading 
the area around each feature, looking around and resolving any conflicts, 
uploading in a small batch, and making sure to tag changesets correctly. 
Ideally, someone would then go back, search for the changesets and confirm 
everything was done correctly. 

http://osmly.com/screenshots/overview.jpg 

That's too complicated for my liking and the pool of users who know how to do 
all this without making mistakes is too small. On the other hand, most of that 
complexity is necessary for organizing the people involved and maintaining some 
quality to the data going into OSM. I want a simpler and more automated way of 
handling the most manual and repetitive parts for really basic imports. I just 
want a simple way for someone with OSM experience and knowledge but not 
necessarily a GIS data or programming background to help out with basic tasks 
and share their knowledge to get more data on the map. 

http://osmly.com/screenshots/QA.jpg 

I built OSMLY to reduce the complexity of doing simple imports with many people 
and many features. It's just the essentials: editing geometry, fixing tags, 
displaying relevant nearby features from OSM, flagging problems and uploading 
to OSM. Features are served from a simple database to keep track of 
everything/everyone and different actions are allowed based on an feature's 
status. Once an item is submitted it's available for Quality Assurance where 
other users can confirm everything was done correctly and flagged results can 
get attention from more experienced users in JOSM. 

http://osmly.com/screenshots/geojson.png 

Technically, OSMLY takes in GeoJSON data and makes sure geometry is valid, 
simplifies, flags obviously difficult items, adds bounds for each item, and 
converts everything to a sqlite database ready to be served up to the world. A 
simple server takes care of routing requests from the browser to database 
queries and returning results. Once the user has received a new feature the 
surrounding area is download from an OSM server and those results are filtered 
for relevant geometry. Then it's all displayed on the map. From there it gets a 
bit more complex depending on the user's actions. 

http://osmly.com/screenshots/basic.jpg 

Some key features: 
* Context - nearby relevant features that may conflict are shown alongside 
the item being edited along with complete tags. Context filtering can be set 
using regular OSM tags. http://osmly.com/screenshots/context.png
* Quality Assurance - administrative users, specified in the settings, can 
review everything that has been submitted and confirm each item has been done 
correctly
* Edit in JSOM - every item can be remotely opened and completed in JOSM if 
you prefer. http://osmly.com/screenshots/inJOSM.png
* Tag Manipulation - depending on your data source, you might not have to 
do any tag manipulation before OSMLY. Tag keys can be renamed, added, and 
removed.
* User Whitelist - specify exactly which users are allowed on an import or 
allow everyone (default)

Limitations: 
Currently OSMLY only works with polygons. Eventually, time allowing, I'd like 
to expand to other GeoJSON feature types (points and linestrings). OSMLY is 
only ment for simple imports so there aren't plans for implementing 
multipolygons or anything else too complex. Some of this is technical but 
mostly it comes down to ease of use. Right now if a complex item is found OSMLY 
pushes the user to edit in JOSM.

===

Re: [Talk-us] Using MapRoulette for imports

2012-12-19 Thread Aaron Lidman
I've been working on something like this, while learning python, which I'm 
hoping to have done by the end of the year. Right now I'm refactoring and 
generally cleaning up my messy code and still testing things out. Here's what 
it looks like right now: http://i.imgur.com/H4srX.jpg It's just basic leaflet 
and geojson backed by sqlite from ogr2ogr from a shapefile that was cleaned up 
before hand. When a feature is loaded it pulls down osm from xapi and checks 
for existing features that will intersect based on predefined tags, in this 
case [leisure=park], [leisure=garden] and a few others. If it intersects it's 
skipped and the next one is fetched. Hopefully I'll have more to post here 
about it soon.
Aaron Lidman


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us