Slashdot Mirror
OpenStreetMap Launches a New Easy To Use HTML5 Editor
SWroclawski writes "On the heels of the news that OpenStreetMap is allowing anonymous contributions with its 'note system,' the project has launched a new in-browser editor called iD, which is not only easier to use, but written completely in JavaScript, using the D3 library for rendering.
With all these improvements, OpenStreetMap is gaining popularity and has started a new donation campaign for additional hardware to support all the new contributors."
This replaces a flash based editor (really great news!). The code is, naturally, available (under the WTFPL).
It was not hard to edit before (I mostly used josm), but lowering the bar is probably a good thing.
What I would like to see is better history viewing. on wikipedia it is quick to see if a page has been edited recently and by who. obviously this is a harder problem for a map. clicking history on openstreet map does not show much of use (right in the middle of an inland city i am seeing edits like "Update harbour tags ").
Interesting how everything is called HTML5 these days.
This HTML5 Editor, it's using JavaScript and a JavaScript library (D3.js).
I think SVG has been an open standard for years, so, the CSS3 transitions make this an HTML5 Editor then?
Is this at least using a canvas?
not actually replaced flash-based editing, but adding another option. You can edit openstreetmap in a number of editors, with a number of different technologies: Some of them are: iD : HTML5-based, in-browser editing Potlatch : Flash-based, in-browser editing via flash player plugin JOSM : Java-based application, run from local machine, or via JNLP Vespucci : Android application, works nicely with touchscreens Meerkartor : QT application Openstreetmap is open, and as such there's loads of different ways of using it (or updating it). I've been contributing to openstreetmap since the days of the java applet editor (which used the processing libraries), before the data structures had been fleshed out. It's come a long way from a few scrawls representing the paths around Regents Park in London.
It takes a few minutes for the changes to get published on the servers. Wait for half an hour and look again.
Is it still wrong?
It can take a while for the geocoder to pick up on issues.
Also, if you put a note on your area and link to it, I can take a look.
Addresses are particularly tricky for a variety of reasons that I won't bore you with, but could make your head spin.
You're right that there is a need to make addresses easier to work with, but in 99% of cases, you can just draw the building and tag it with the address and all should be good.
OSM is great, it beats Google in my part of the world, and I find drawing bike-tracks a very relaxing alternative to Solitaire. But right now the level of detail I can add to my neighborhood is really limited by the rendering engine. JOSM has a nice plugin for turnlanes, for example, but they don't show up on the map. JOSM shows icons for a carwash, but hese don't make it to the final map either.
10 ?"Hello World" life was simple then
C'mon guys; give us a reference platform, or maybe even kickstart it, and I'll drive around with a device stuck to my car dashboard or bike windscreen.
Hell, I'll even pay you - say - $100 bucks for the device. OK, twist my arm and I'll go to $150. Should pay for a cheapo camera, GPS, a battery and some memory.
But, pretty please, no fucking around with obscure stuff. I'll tell it where it starts, where it stops, and plug it into the 'net once a day, or week.
Maybe if I have time, I'll name the streets, if I know them.
But again please, could you make it EASY.
All the commercial orgs piggybacking off this project should be able to kick in a few bucks for the servers and technology to stitch the raw material together, blur faces & plates, eh? Am I alone?
The issue isn't equipment, it's storage and bandwith.
If you collect a small city's worth of data, you'll have quite a lot of images. Maybe only a terabyte, if you're lucky, but probably several terabytes. Now extend that to an entire state/province, or a small country. You'll quickly be racking up terabytes and pedabytes of data.
"No problem, storage is cheap." you might be thinking, but storage gets expensive as you increase the demands of the storage. All of this storage needs to be available immediately, so it can't be stored on near time storage devices, which might make it less expensive. And it must be stored in such a way that makes it redundant in case of hardware failure, so either using disk, or system level data replication.
And now that you've stored the data, you need to serve it to users. Pushing out a small amount of data to a user isn't a problem. 2 cents a gigabyte seems cheap. But if you need to serve a whole country worth of data, with tens or hundreds of thousands of users, you now hit bandwidth issues- bandwith caps, and overage costs. Getting a larger pipe to the user costs more money, and deals that seemed reasonable start to become very expensive very quickly.
You'd quickly start talking about needing to spend hundreds of thousands of dollars just to store the data, and then hundreds of thousands (or more) to serve it out.
Commercial organizations are not going to be inclined to put money towards something when they don't have to, and the burden on users would be incredibly high.