Recent diary entries
Being a relative newcomer to OSM, I was surprised to find little data on Melbourne's tram stops. With the largest tram network in the world and over 1,760 stops on the network, it is a large project to complete.
With my local knowledge and some field trips, my aim is to input as much information as possible for each stop using tags. I have completed all of the route 48 stops as a sort of pilot, and many other routes will overlap.
I am particularly concentrating on the following attributes:
Any other attributes will be added as needed. I will record each route as I complete it, in no particular order.
Hopefully I can cover all 1,763 stops soon!
- Route 109
- Route 48
I've been trying to run through task "#1024 - Nepal Earthquake, 2015, Severely damaged housing areas and IDP Informal camps, Gorkha" using some of the post-quake imagery captured by DigitalGlobe on the Wednesday after the quake. I am looking at a tile of imagery from a very rural area.
Because it is monsoon season, Nepal was covered by quite a lot of cloud for a few days after the quake, and the imagery I am working on, from the 29th April 2015, isn't very clear. There is cloud cover over the majority of the tile and this image has very high off-nadir angle, so the recently digitised building footprints do not line up with this imagery very precisely. However, it's the best that is available, and it's what I have to use.
To my interpretation, it seems that most of the buildings that are visible on my specific tile held up pretty well. The majority of rooflines seem to be present and there doesn't appear to be rubble cascading away from the building sides.
Sadly, there is an exception. One particular building footprint stood alone, someway down a valley, and was clearly in the path of a landslide. Comparing the new imagery back to the pre-quake Bing image, it seems like this building has just gone. If anyone was inside when the landslide happened they wouldn't have had much of a chance.
I am sure when better imagery arrives we will see many many more damaged or destroyed buildings - but that doesn't make this one any better :(
Thanks Hedaja, SK53 and Alan for putting me right - The images are deceptive! I appreciate the hint to use OpenCycleMap to use the contours. Learning heaps!
It's now been around 2 years since I started editing OSM seriously. I've used Pascal's HDYC and YOSMHM to track my progress, with the goal of making a real contribution to OSM worldwide. One thing I always wondered about, as my OSM node rank went up. It would reach, for example, 300, and I would think, wow, I have been editing so much... who are these 299 people around the world who actually edit even more??
Recently, I set out to answer this question. I started looking at HDYC for well-known accounts, as well as their heatmaps, and gathering the results in a spreadsheet. When that got tedious, I wrote a C++ app on Osmium and ran it on the Planet.osm file, to find out the complete list of top-ranked accounts.
And the answer is... most of them are not actually people; a few are bots, and many are "import accounts", or user accounts that have been used for a large import at some point. (...but not all of them! Some are actual, live humans manually editing OSM longer and more extensively than me). Along the way, I learned some OSM history, and the diverse patterns in OSM in different countries.
Here is a link to the spreadsheet, sortable by rank, with my own notes on the where/what of around 385 accounts, including the top 100 in node and way ranks. The data is approximate... it's not auto-refreshed by a script (yet), so some ranks may be a little out of date.
In my next diary entry I'll share some of the stories and realizations I've had while gathering this data.
edits in Klettgau area, mainly on trees. Reminder: shape of natural reserve 'Widen'. To be checked.
Now we have at least 3 hard to detect version on the database. Can you spot a difference?
name="McDonald’s" ( count=126 ) U+2019 ’ e2 80 99 RIGHT SINGLE QUOTATION MARK
name="McDonald´s" ( count=40 ) U+00B4 ´ c2 b4 ACUTE ACCENT
name="McDonald's" ( count=14041) U+0027 ' 27 APOSTROPHE
see more: http://en.wikipedia.org/wiki/Apostrophe
With the drained out battery of GTA02 but a handy Sony CycleEnergy battery bank was able to trace from Midson to Marsden Rd. As usual the initial fix too bit of time(can't blame, it was cloudy). Got a lift too in Ashram car. The trace was immediately transferred to my laptop.
There was bit of a mess created at the time of submitting the trace in google map. It introduced a new layer concept which I couldn't understand and created a new layer which I found unusual and tried to delete the layer that I created which deleted the whole of the trace :( . There is no way to recover the trace.
The traces submitted here is going to help me to get the traces.
Apple has just approved Open GPX Tracker
Open GPX Tracker is a GPS logger for iOS (iPhone, iPad, iPod). Track your location, add waypoints and send your logs by email as GPX files.
This app has no annoying time restrictions, no ads and no in-app-purchases. Create unlimited GPX traces :)
Requires iOS 7.0 or above. Open GPX tracker is an open source app.
Note: Although, the app supports several tile sources such as OSM, the version published on the App Store, displays Apple Maps.
Here you have some links:
Details about iD editor users get publicly, permanently and silently logged with every edit – a privacy breachPosted by aseerel4c26 on 1 May 2015 in English (English)
Since the recent (estimated: two days ago) update to version 1.7.1 ("Add basic browser and platform info to changeset tags (#2559, #2449)") of our editor iD it publicly, permanently and silently logs operating system, browser and language details (+ more) for every user, for every edit by adding those tags to a changeset (example values follow; or see /history and pick a random one until you get one by iD):
browser = Chrome 37.0 locale = it-IT platform = Linux
- I could imagine good uses for this big pile of data ... e.g.
- it may help in debugging the editor
- one could potentially make nice statistics of our user base in total from this data (from a dump), or
- use it for quality assurance heuristics (e.g. it may be more suspicious if a foreign language user edits at a specific place),
- But I also could imagine bad uses for this big pile of data:
- it also enables everybody to create detailed statistics about a single user's browser update habits and browser name
- or operating system switching over time. Which all is not why people contribute to OSM.
- Language, Browser name, exact version and operating system name may make a contributor identifiable among a big group of persons, especially if some of those details are not very usual (think of someone speaking Lithuanian using Epiphany under Linux and editing in an Argentinian city – the expectation of only contributing under a pseudonym user name is quickly broken.
- The users have practically no chance to ever remove this information about them.
In the linked issues (found via the release comments) 2559 and 2449 I see no rationale at all why all this data needs to be saved 1. publicly, 2 permanently and 3. silently. Just reasons why the data could be useful are mentioned (similar to my ideas above) but not why the privacy and trust of our contributors needs to be hurt in this extent. Note: I have messaged the three involved developers/issue reporters via OSM mail about this post.
I think this recent change is really over the top and is doing harm, because to outsiders our project may seem as if it does not care about our contributors' privacy and fools new users by silently publishing information about them. I would hate it if, in the future, I would need to pass along a big warning about privacy when I try to attract new contributors.
Of course a simple workaround is to use another editor, e.g. JOSM, which I suggest doing for other reasons anyway.
Please, let's quickly remove this personal data canon before even more data is collected. By the way, I am intentionally not writing in a hidden bug tracker to make everybody aware of the problem and hopefully sensitise the developers a bit.
First day learning OSM today and can do it and digitise easily, Now familiarising with the terraced rural areas of nepal and digitising buildings paths and rivers.
IS THERE ANY API, DOCUMENTATION ON HOW TO GET STARTED ????
As a newbie, I am reluctant to comment, but I feel that some of the features tagged as rivers are in fact the tops of mountain ranges.
Hi am using a different approach navigation to use the search a good discussion
satellite image not updated. new roads not available for edit.
I have previous experience in identifying features in historic and modern maps and I didn't know that I could us this skill as a means of helping ... but I do now!
So here I am, I hope that I may be able to help in any little way that I can and I am learning so much in the process, what OSM is about and how it can be used to help.
This is a brief, but hopefully friendly opening to why I am here and my experience today.
Osm2pgsql 0.87.3 has been released. This development release primarily fixes bugs, but some of the bug fixes make other features usable.
Included is a bug fix for the lockfree queue implementation. Anyone using versions 0.87.0 to 0.87.3-dev, parallel processing, Boost 1.53 or newer, and not using --without-lockfree should immediately upgrade or stop using parallel processing. No data corruption issues have been observed, but the lockfree implementation may have been buggy on all systems.
There have been various fixes with moving hand-written C structures to C++ standard library equivalents and other code cleanups. The main user-facing changes are
The multi-backend should now be functional, with an example which creates separate tables for bus nodes, highways, and buildings
--without-lockfree is no longer needed on OS X, BSD and some Linux distributions and architectures. This should simplify downstream build scripts for multi-architecture builds and improve speed on any OS that required the option before.
nodecachereader should now work with node IDs > 2^31. This is a separate utility program, and obviously isn’t used much
Nominatim-related performance improvements
Many autoconf macros have been updated. This should ease configuration on non-standard systems.
This may be the last tagged release that does not require C++11. We have no current PRs which will require C++11, but would be willing to accept them.
A full list of commits is at https://github.com/openstreetmap/osm2pgsql/compare/0.87.2...0.87.3
As always, bugs can be raised at https://github.com/openstreetmap/osm2pgsql/issues. I’m particularly interested if package maintainers have concerns. If osm2pgsql isn’t packaged for your OS and you want to do so and have questions about the osm2pgsql side, please ask them too.
Many thanks to those who have contributed code to this and previous releases.
On behalf of the osm2pgsql maintainers
Minapa ko yung eskinita kung saan ako lumaki. Wala lang.
I love you Jen
People who have read Gary Gales blog post on Geohipster will have noticed that one of his claims is that OSM is "business unfriendly". It is a reoccurring theme in discussion with people from the geo-industry however in many many discussions and contacts with companies outside of geo** it has never been an issue, and so the question should probably be reformulated as:
Is OSM geo-business unfriendly?
Well, my answer is, you expected this: no.
It is obvious simply by observing the many thriving businesses that would not exist without OSM and the way OSMs "business-model" is structured.
By positioning itself as a data collection project OSM has left lots of space to build businesses using OSM data and providing services on top of it. This is in stark contrast to say Wikipedia, which has always positioned itself as the one-stop shop for WP content and services.
Would a MapBox exist if OSM had chosen a more Wikipedia like model? Naturally not. Would MapBox cease to exist if OSM changed its mind today? Probably not, given that they have moved away from being a one-trick pony, but it would be the death knell for a number of other players.
But no fear, a further reason that OSM is extremely business friendly is that we have held a steady course over the decade the project has existed. Major changes have taken place over a long period of time with lots of time to adapt.
Now there is a certain slow feature creep with respect to features provided on the central OSM site which will continue to raise the bar of the minimal functionality for a viable online map portal, but anybody endangered by this should likely rethink their business model in any case.
Community run and developed software and services will likely have more impact. OSM provides a level playing field and your business model should take competing with non-commercial services in to account.
On top of the above OSM is extremely cheap for business. Not going down the Wikipedia route has enabled OSM to produce all this good stuff with a minimum of fixed costs. The annual budget of the OpenStreetMap Foundation (the formal body behind OSM) is roughly a 1/1000th of its Wikipedia counterpart, the Wikimedia Foundation. There is no obligation for a business to donate to the OSMF and a major part of its income has been from donations by individuals.
A further common complaint from the geo-business pundits is that the OSM community is business hostile, however occurrences of this can essentially always be traced back to the company in question trying to force something on the community, or trying to telling the community what to do instead of being part of it.
Matter of fact the OSM community has an extremely laissez faire attitude towards business involvement in OSM. It is difficult to find somebody opposed to building businesses on the volunteer work, and the boards of two of the most influential OSM related organisations (OpenStreetMap US and the OSMF) are dominated by industry representatives. Dominated as in: a single token non-industry involved member in each.
Garys superficial main beef with OSM is however the current distribution licence, the ODbL.
Over many decades essentially all businesses dealing with geo-data have had business models where they would obtain data from various sources, add in some self-surveyed information and sell the result either directly or services built on top of the resulting dataset., negotiating contracts at every step in the process. This goes for essentially every player from Tomtom, Nokia and google at the top, down to smaller players, excluding essentially only the national and regional government operated GIS departments. Doing business this way is deeply ingrained in the thought patterns and culture of the whole industry.
The advent of open data, mainly open government data, has not changed this. What it has changed is that the cost structures of the businesses have improved. You shouldn't be fooled by the marketing, many of the “disruptive” geo-businesses are simply using the tired, age old business model with lower costs. The benefit is that they seem to have a bit more lee way to do cool things right now, but that will change when everybody has caught up.
OSM is the odd kid on the block- Now I don't want to dive in to yet another licence discussion. As has been pointed out many times, many of the issues with the licence are make believe, the real main issue the geo-industry has with OSM is that we don't conform to their traditional business model and they are having problems to adapt. You can't simply haggle a contract with OSM, everybody gets the same.
With other words: their problem is that OSM is truly disruptive and different.
Is this “business-unfriendly”? No, it opens up lots of opportunities for geo-businesses that are willing to adapt, for the others: its capitalism, bye bye.
** it should be noted that non-geo businesses don't seem to have problems googling for the OSMF and sending mail or e-mail with inquiries and questions. The geo-industry on the other hand seems to be so ripe with google-challenged people that it was possible for MapBox to fill a full “legal” marketing piece with complaints by them.
New to OSM, these past few days have been my first steps onboard. I've been meaning to contribute to HOT for a while, and the Nepal event finally spurred me into action. I put in about 3k building footprints on the day after the earthquake - back then they were some of the first building footprints in the rural areas. Pretty proud of that. Now, 6 days later, it is hard to find unmapped buildings! The swift progress on this data capture is amazing to see.
I've certainly learnt a few lessons along the way about doing things the OSM way, thanks to some of the HOTOSM user community. Very welcoming.
In 4 days time I am hoping to put as many volunteers from our office as possible to the task; I'm expecting somewhere between 8 - 15 people to be involved. Hopefully we can make a pretty big dent over the course of a day - and with luck some of the folk will carry on in their spare time. We will see how it goes.
You might know the opening_hours statistics page which was created for the current weekly task about opening hours on http://blog.openstreetmap.de/. The statistic is all about how many opening hours and related tags are in the dababase and if they are machine readable. But the really interesting question is can those opening_hours itself be visualized so that you can draw conclusions from it? This question occurred to me after I mentioned the weekly task and the statistics page to a colleague of mine (not yet a mapper). He asked if this statistic does actually show something useful for example the average opening hours of all amenities in OSM. This was something I had not thought about but I also found this question interesting. So I thought about how this can be visualized. I came up with the idea of showing the percentage of open (unknown counts as closed) amenities for a given time of the week as known from GitHub activity punchcards. After the idea was there the implementation could not wait long :) And here it is: