joost schouppe's Comments
Post | When | Comment |
---|---|---|
Potlatch 2.5 | Looks like the json you point at is not updated anymore. The correct link is mentioned here: https://github.com/osmlab/editor-layer-index/issues/305 |
|
Potlatch 2.5 | Yes it does. Thanks. Sorry. |
|
Potlatch 2.5 | Ooh, noticed another issue: when you click on an inner way of a relation, you get the relation tags (but the outer way is not selected), and there seems to be no way to edit the properties of the inner way (say a residential area within a meadow) |
|
Potlatch 2.5 | Oh, both seem to apply :) Some of the layers are in fact 16th century state of the art. And all of them seem to be missing from that JSON file. I’ll follow up on their issue tracker. |
|
Potlatch 2.5 | The list there does not seem to be used by Potlatch, and I understood that it it should (as in: is programmed to do so). I’ve only checked with the imagery available in Belgium. |
|
Potlatch 2.5 | I had hoped the update would have fixed the issue with editor-layer-index imagery not being available in Potlatch. Unfortunately not the case. |
|
You can add it. But should you? | I agree that the level of detail we want to achieve should be limited by our ability to keep it up to date. That said, we’re constantly working to increase our ability. Say you map you neighborhood in crazy detail. All it takes is finding a few people half as crazy as you to keep that work up to date. I’ve noticed how new mappers have different interests then “old” mappers: some of them like to add ever more detailed stuff, but others love fixing mistakes or reviewing existing work. The argument about authority is a bit strange to me. We are not an authority on anything, all our data is free to deteriorate, be it for lack of updates or wrong edits. So your argument seems to lead towards an empty database. Even the “nobody is going to use it” argument is a bit strange to me. It’s only after the fact that you can evaluate this. In fact, I don’t believe the growth of scope and detail in OSM is limited by any guidelines. it is only limited by what mappers want to map. And that seems to be working pretty well in general. |
|
A valuable find - free parking in Florence | I’ve used impromptu=yes for situations like this. It’s mostly used to mark camp spots that are used but not official |
|
Processing MapSwipe output for the HOT Tasking Manager | Is the MapSwipe output available for download somewhere? |
|
OSM & government, in Lithuania | Hi Alan, Depends on the volume and what exactly you want to achieve. For exploration, QGIS is quite practical. You can just drag and drop shapefiles, you can add OSM tiles as a background and there’s all sorts of ways to add OSM data. Then you can do some spatial analysis to find (mis)matches. But even umap or mapcontrib might work, depending on your goals. |
|
Evolution of road network length in Flanders | Thanks Glenn :) Wednesday is OSM day, that’s when this happens. However recently most of that time goes to organizing OSM stuff, rather than analysis. |
|
Evolution of road network length in Flanders | Thanks @PlaneMad! Well, in fact, what I wanted to show is that “mapping priorities” do exit, but they are not absolute. Yes, the most important stuff gets mapped first, but as they get mapped, some other people are already working on more details. Which is great, because by the time the “big stuff” is ready, the smaller stuff has already found its data model. I think part of your answer is already there: yes, as geometry edits go down, tag edits seem to increase. And then we’re talking about details. Turn restrictions are tricky, as they are relations and the osm-history-importer doesn’t do that. In fact, using the scripts I have lying around, I can give you the numbers for all the things you mention. I’ll get around to writing about them; but publish them here asap I have the splitter and importer in a local Vagrant instance, and post processing is just based on flatfiles using SPSS scripts (which are easy to read and translate to something more open). I’ll try to find out how to share that. Then it shouldn’t be very hard to replicate stuff like this. |
|
OSM Node Density – 2016 Update | Damn, there goes another week-end =) Thanks! Looking forward to playing around with this. |
|
OSM Node Density – 2016 Update | Would it be very hard to get the node density of Europe on this grid? Would be kind of interesting to make a little analysis of the correlation between the two - and patterns of exceptions. Thinking about something like an analysis by clusters of squares like shown here (every slide adds or substracts 10% of the total European population)
|
|
Evolving roads | I do use the splitter and importer from that toolchain, but I used psql2shp to extract the data I needed. (I don’t know enough Postgres to be able to do much rendering directly from there, and the renderer itself uses the previous generation OSM rendering which I don’t know how to tweak) |
|
OpenStreetMap Community Statistics Revisited | Simon, I don’t have any previous experience with working with changeset dumps, however a huge file with the basic ingredients to generate the stats you made would be very useful for me. As I don’t speak but do read SQL, even the throwaway code would be interested if ever I get around to doing something with the changeset dumps. |
|
OpenStreetMap Community Statistics Revisited | Is it easy to share a slightly rawer file too? I.e. a row is a contributor (or the unique combination of a contributor and the editor used), in the columns country, date, editor1, editor2. Also, the source code zips seem to result in 1 kb files. |
|
Raster gpstrace tiles as OsmAnd overlays | And the same can be done with Strava traces, about which I wrote a blog :) We should totally add this to the Osmand wiki pages here (if it ain’t already there) |
|
Test | Looks like your test succeeded. |
|
An open database of inconsistent edits observed on OSM from OSMCha | First, great stuff that all changesets can potentially be reviewed, and reviewed only once! If dreaming is allowed, it would be nice to have as many tools as possible connect with a “revision database”. For example, we use welcome.osm.be to review the first few changesets of new contributors as well as welcome them. Some of those edits are already fixed by an active reviewer, and they might reviewed a third time using your tool. One way to avoid this, is to expand the capabilities of OSMcha itself. A necessary extra change would be to allow filtering by admin area instead of bbox. A bit more complicated: a lot of those newbie changesets are just “slightly wrong”, e.g. adding a path without a connection. Should there be a distinction between “harmful” and “needs fixing” or is the point just to find things that need fixing, regardless of ill intent? Another feature worth dreaming about is to implement #pleasereview. This is an idea to allow people to self-flag their changeset to trigger human review. It would help the less confident mapper in their growth and help other mappers understand changesets. Implementing it on the OSMcha doesn’t seem to need any special additions, maybe just a tracking tool at the stats page. The bigger thing would be to ask the iD, JOSM and Maps.me developers to add a feature to help add this tag to the changeset comment. The idea is explained a bit more here. |