Recent diary entries
Now despite the difficulties of garnering attention when your app doesn't break things, Vespucci development has carried on and I'm pleased to announce that the first "official" beta release of 0.9.9 is available from googles play store and from our github repository.
While there are quite a few user visible changes, most of the work since the release of 0.9.8 has been under the hood, improving the maintainability, testing, documentation and code quality throughout the app, making it much easier to contribute to its development.
It should however be noted that Vespucci has a relatively large code base and contributing to the code (but not to the documentation, presets and other aspects of the app) remains fairly complex. See vespucci on OpenHub for more on that.
The release notes give an overview of what has changed, here just some highlights:
- an Indoor mode see wherecamp blog post
- tag and preset based filters
- way improvement handle use now follows the same pattern as iD
And where is the elusive openinghours editor? I've resumed work on it and there is a reasonable chance that it will be included in the 0.9.9 release even though there is still a fair bit of work to do.
In November 2015 I produced a blog post on the relative sizes of our national communities and their development over time. When I updated the contributor stats on our wiki a couple of days back and looking at the massive impact the influx of first time users using maps.me have on the contributor numbers (not necessarily on anything else as I have pointed out in earlier posts), I thought it would be interesting to update the numbers and have a look at what has changed over slightly more than a year.
The most notable changes in the top 20 ranking by absolute community size are Russia overtaking France, Ukraine moving up 6 places and the Philippines moving in to the top 20 at the expense of the Czech Republic.
It is reasonable to assume that these changes are mainly due to the differences in the popularity of maps.me, No surprise and expected that it is most popular in Russia and the Ukraine, not so clear why it is so popular in the Philippines:
Numerous small changes in the contributors per capita ranking, but I suspect the fact to take away from this is that even in countries that already had the best results we are still improving the penetration levels.
In the first blog I singled out Germany and the United States as the two largest communities with very different growth patterns. Particularly in Germany there has been some concern as both the number of active contributors over short periods and the absolute number of edits have been decreasing slightly over the last two years. However new contributor influx does not show the same trend and we might put the “negative” trend simply down to the major urban areas of Germany being extremely well mapped.
As in 2015 the trend in the United States is very different, with a very large growth peak in December 2016. 3500 mappers in a month is roughly what would be required to grow at the same rate relative to population as Germany, so this should be a great achievement.
Unluckily it is not.
Closer inspection shows that a large number (in the 1000s) of the accounts created in December and in the proceeding months are fake accounts created by one or more SEO companies. While it is rather unclear if the data added itself is legit, the accounts themselves are not.
Back to numbers with a more positive context, the continental distribution of mappers continues to even out, while Europe continues to dominate, both Asia and South America have increased their relative share.
Three years back I started sending welcome messages to new mappers on behalf of SOSM, using a simple tool chain based on the RSS feed of new mappers from Pascal Neis.
The message is not customised as from the beginning it was seen as a replacement for the welcome message that had gone away with the web site redesign. The text (in 4 languages, no Romansh version though) is designed to welcome the new contributor and give pointers to the resources available nationally.
Has it worked? Difficult to say, as the whole point was a replacement of something that existed before, we didn't expect drastic change and we didn't get it.
And, no, I'm not stopping :-)
Two weeks back I was invited to Wherecamp Berlin, on the one hand to participate in the opening panel and on the other to have a short talk on the state of indoor mapping, more about that later.
Naturally the foreseeable impact of self-driving vehicles and machine learning in general was the, obvious, main topic of the opening panel. But outside of “things are going to change” I’m not sure that there was any other conclusion from a couple of oldish men without crystal balls.
From an OpenStreetMap point of view it was encouraging to see so many OSM based projects and operations presenting at the event mingling with essentially all the big names in geo-business.
Stefan from GraphHopper presenting at Wherecamp Berlin.
From a bit of a nerdy view, the first day presentations from Qualcomm, Broadcom and Google on what we will likely be getting in the way of GNSS support in upcoming mobile phones was quite interesting.
At the conference the first phone (the Aquaris X5 Plus) officially supporting the Galileo system was presented together with hackathon arranged around it. I didn’t get to actually testing one, so no further comment on if it actually worked and if there was any noticeable improvement. This seemed to be part of a marketing campaign that will lead up to Galileo being declared operational this December if all goes well. This probably doesn’t really mean much from a practical point of view as the number of working and commissioned satellites will still be rather low, but it probably does indicate that Galileo is slowly becoming real.
Qualcomm however did announce in their talk that all phones based on a current Snapdragon processor should support Galileo, naturally likely needing a corresponding firmware upgrade first. Slightly humorous was numerous of the presenters referring to the Samsung Galaxy S7 as an example of such a phone, even though in Europe the S7 uses a Samsung Exynos processor (which however, even though not documented, I suspect will support Galileo too).
Perhaps the most interesting talk in the series was from Broadcom on their project to develop a dual frequency consumer grade GPS chip. Dual frequency GPS chips have up to now been the domain of survey equipment manufacturers and the military. Naturally it is questionable if this technology will actually make its way in to real consumer devices, but if it does, we will get significant better GPS data without resorting to using DGPS with external reference stations.
This brings us to the last of the three GPS related topics: as you may have heard google will be supporting receiving “raw GPS data” from your mobile phones chip set (if it supports in the 1st place) from Android Nougat on. This implies that you could use your phone as a “rover” in a typical RTK setup or simply post process GPS data for better results. But this really all only makes sense if you have access to reference data and if google is going to provide something in the way of that is currently completely unclear.
Besides inviting me to the opening panel, the organizers had twisted my arm a bit to participate in the afternoon session on indoor mapping in OSM. Background: slightly over two years back I was involved in the effort to devise a reasonably consistent and simple tagging scheme (see: https://forum.openstreetmap.org/viewtopic.php?id=25961 ) to replace the previous IndoorOSM tagging that was a bit popular at the time, but had a couple of technical problems and was in general rather complicated. The result of that work is SIT, but when we were working on the scheme we had one big problem: we really didn’t have any working code and only a small number of examples to work with and so when we finished the first version of the specification in 2014 it was not really clear if everything we had designed would work.
Floor plan elements in OSM, IndoorOSM blue vs. SIT red.
Fast forward to 2016, those of you that participated in SOTM 2016 may have seen by the talks by Cynthia Gutton. Antoine Riche and Adrien Pavie on the SNCF mapping 388 french train stations. The tools (among others iD-indoor and openlevelup) developed in parallel and for this project, brought indoor mapping large steps towards being, even if not completely mainstream, something that can be reasonably done in OSM. Antoine and Adrien repeated their SOTM talk in Berlen, and additionally we saw presentations from DB (Deutsche Bahn), Mentz, and OpenStationMap on their mapping of train stations in Germany and elsewhere.
One point that I stressed in my talk at the end of the session, is that while from a number of aspects indoor mapping is a good fit for OSM, for example because we can seamlessly integrate pedestrian and accessibility routing outdoors and indoors, if comes at the cost of extreme amounts of details that make editing essentially impossible without dedicated editor support. Adrien has already proved that this can be done in a reasonable fashion with iD-indoor, not to be outdone I threw together a proof-of-concept for Vespucci for the conference (in the mean time this has reached a quite stable status).
Berlin main station in Vespucci indoor mode.
In other News
One of the more intriguing presentations on Sunday was from the company TerraLoupe “Aerial large scale landmark detection via deep learning". While who is actually the contractor remains in the dark, the interesting aspect was using machine learning to identify objects (for example emergency phones), text on street signs etc. along German motorways by using high resolution oblique aerial imagery.
Also of note was the presentation by Holger Dietrich on a version of the Wheelmap app with support for google Tango devices (currently the only such non-developer device is the Lenovo Phab 2 Pro), which allows surveying 3D objects, in the case for Wheelmap for example the width of an entrance and step heights.
Slides from the talks are available from the conference webssite.
Einige Leser haben vielleicht einen leicht genervten Tweet von mir gesehen als ich diese Woche entdeckt habe, dass die Vernehmlassung über die Revision des VGWR an uns vorbeigegangen ist, ohne dass wir die Möglichkeit hatten unsere Meinung dazu anzubringen.
Um was geht es?
Das Gebäude- und Wohnungsregister ist ein schweizweiter Datensatz der sämtliche bewohnte Gebäude und Wohnungen in der Schweiz umfasst. Neben Merkmalen die für OpenStreetMap nicht interessant sind, enthalten die Daten auch einen vollständigen Adressdatensatz und zum Beispiel auch die Anzahl Stockwerke für jedes Gebäude. Die GWR Daten sind zwar nach der jetzigen Rechtslage nicht direkt in OSM nutzbar aber wir haben immerhin Zugriff auf einer daraus erzeugten Strassennamensliste den wir zur Qualitätskontrolle nutzen.
Aus den GWR-Daten generierte Adressen werden von SwissTopo auch auf map.admin.ch angeboten, auf welcher Rechtsgrundlage die Publikation beruht ist allerdings völlig unklar. Dies tangiert OSM insofern, dass in der Schweiz man keinen urheberrechtlichen Schutz so publizierter Daten erwarten kann, und der Nutzer somit auf magischer Art und Weise wissen müsste, dass das aktuelle VGWR eine abschliessende Aufzählung der erlaubten Nutzungen enthält und diese Daten in keiner Art und Weise für OSM genützt werden dürfen. Eine ähnliche Problematik stellt sich auch mit öffentlich zugänglichen Datensätze dessen Nutzung im Geoinformationsgesetz geregelt wird, aber immerhin muss man da nicht ganz so obskure Kenntnisse der Rechtslage haben um sich richtig zu verhalten.
Was soll sich nun ändern?
Der definitiver Text des revidierten VGWR, der Anfangs 2017 in Kraft treten soll, ist nicht verfügbar, deshalb bezieht sich diese Analyse auf den für die Vernehmlassung verteilten Entwurf. Dieser regelt viel administratives neu, zum Teil aus föderalistischer Sicht durchaus nicht unproblematisch, und erweitert das GWR um die nicht bewohnten Gebäude. Relevant für OSM sind vor allem aber die folgenden Punkte:
- Die eigentlichen GWR Daten bleiben weiterhin nicht nutzbar, da ein vollständiges Verbot der kommerziellen Nutzung besteht.
- Im Rahmen einer gleichzeitigen Revision der Verordnung über geographische Namen (GeoNV) wird die SwissTopo ein amtliches Adress- und Strassendatensatz aus den GWR Daten erstellen. Dieser Datensatz wird die Zugangsberechtigungsklasse A (öffentlicher Zugang) erhalten.
- Die SwissTopo wird verpflichtet mit den aus dem GWR abgeleiteten Adressdaten ein Geokodierungs-Dienst zu betreiben
Gibt es demnächst einen schweizweiten Adressdatensatz den wir nutzen können?
Man muss natürlich wissen, dass Verordnungen vor allem von den betroffenen Ämtern geschrieben werden und mit Sicherheit SwissTopo genau diese Bestimmungen im Text haben wollte. Problematisch ist das zwar die Berechtigungsklasse A für die Adressdaten festgeschrieben wird, dies aber nur eine notwendige Voraussetzung für die Veröffentlichung als offene Daten ist und nicht eine solche vorschreibt. Da von den aktuell 63 von SwissTopo auf opendata.swiss angebotenen Datensätze keine einzige zu offenen Bedingungen angeboten wird, kann davon ausgegangen werden, dass dies auch bei den Adressdaten nicht anders gehandhabt wird.
Der weitere ordnungspolitische Fehltritt findet sich darin, dass SwissTopo "verpflichtet" wird Geokodierungs-Dienste anzubieten. Wären die Adressdaten tatsächlich offen und frei verfügbar, könnte jeder, mit geringem Aufwand, selbst einen solchen Dienst gratis oder gegen Entgelt anbieten. Der Verdacht liegt nahe, dass die wirkliche Absicht ist das Dienstleistungsangebot der SwissTopo und ihren Marktanteil auch weiterhin zu sichern und keinen Markt für solche Dienstleistungen auf Basis der „offiziellen“ Daten entstehen zu lassen.
Was bedeutet dies für OpenStreetMap?
Aus OSM Sicht wird es vielleicht möglich sein die Adressdaten zur Qualitätssicherung zu verwenden, wie wir es bereits mit einigen kantonalen Datensätzen mit restriktiven Lizenzbedingungen machen. Wir können auch hoffen, dass die verbleibenden Kantone die solche Daten selbst sammeln, diese uns dann zu offenen Bedingungen abgeben da in der neuen Konstellation eine, auch nur potentielle, kommerzielle Verwertung völlig aussichtslos sein wird.
Da wir mit den kantonal Berner Adressdaten zusammen wohl bald 2/3 der Schweizerischen Adressen zur Verfügung haben und unsere Abdeckung laufend besser wird, sind wir auf gutem Weg den wirklich offenen Adressdatensatz für die ganze Schweiz anzubieten.
As at the begin of every new quarter since a couple of years, I've updated the Contributor Statistics on our wiki.
Naturally the most noticeable thing is the large jump in new users and active users starting in April 2016, which is naturally mainly due to new incoming edits from maps.me users. This is, on first principles, naturally not a bad thing, and annoyances due to bad edits aside, exposing more people to OSM is good.
What I have however noted in discussion is that the impact of the growth of the raw number of contributors is massively overestimated. For example the number of edits (not changesets) per month is essentially unchanged:
Which is not a surprise given that a maximum 0.18% of the edits per month in 2016 to date have been made with maps.me even though at least 1/4 of the active users used the app in the relevant periods. A preliminary comparison with editors that started off with iD show that over the same period the total number of edits per contributor using maps.me is smaller too.
There may be some longer term gains that we can't see yet, at least anecdotally I've seen one maps.me user do an initial edit and then switch to iD, but the numbers indicate that right now that is the absolute exception.
[Update] Small clarification: the 0.18% number includes all maps.me edits not just new contributors.
Last week we released version 0.9.8 of Vespucci, see http://vespucci.io/help/en/0.9.8%20Release%20notes/ for what is new.
This was a bit earlier than expected and does not yet include the opening hours editor (but does include a form editor for conditional restrictions) because we couldn't update the 0.9.7 version on googles play store any more.
The versions available from google and amazon have been updated, we are in contact with the person responsible for the F-DROID build but we cannot provide an ETA for release there yet.
Both APKs are available from github https://github.com/MarcusWolschon/osmeditor4android/releases signed with the same key as the versions distributed via googles play store so you can download and replace your existing installation without issues (you will have to, at least temporally, allow side loading).
The production version available via the play store will however, thanks to googles divine intervention, not be able to be updated till we release 0.9.8. It is however, besides github, available from Amazons app store .
Like a broken record (hmm can youngsters actually relate to that?), at the end of every quarter, I've updated the contributor statistics on our wiki.
As you may remember there was an unexplained big drop in December of last year, the new numbers show some recovery from that, but not to the 2nd and 3rd quarters of 2015 levels.
We're well on the way for the next Vespucci release, a rough list of what I'm working on can be found on github. Numerous changes have already been implemented, here I just want to touch on the most interesting one for now.
Long time users may remember when the tag editing UI looked like:
The image is from version 0.7.0 which dates back to 2011/2012 (before I even knew it existed), I haven't been able to find older screen shots, but I suspect it looked similar in 2009 in the first version. Mid last year I refactored the tag editing code to support a multi-page view and lots of other improvements, resulting in:
One of the goals of that effort was to make extending the tag editing UI easier and that has now beared fruit in allowing a simple preset-driven form based editing interface to supplement the old key-value editing:
This might sound straightforward, however there is no guaranteed one-to-one matching of presets to OSM elements which may have attributes for multiple real-world objects tagged (finding the correct preset is key to determining the correct values for each tag). I've taken an iterative approach to addressing this by trying to find the best match, adding all tags that belong to that preset, then adding all tags from linked presets and then repeating this for the remaining tags and so on. So far the results look good.
There are still a couple of rough edges which need to be smoothed out, but I expect a test build with this feature to be available in a couple of days.
Update: first beta with new UI https://github.com/MarcusWolschon/osmeditor4android/releases/tag/0.9.8-beta-1
As every quarter I've updated the contributor stats here
- ~580'000 contributors total to our map data
- ~163'000 contributors in 2015
The two most newsworthy points are likely that we manged to hit exactly 9999 new contributors in November and the large drop in new contributors in December (which is supported by pnormans recently published numbers too).
Yesterday evening the release version of Vespucci 0.9.7 hit the google and amazon app stores. While not quite as fast as I intended, we did manage to get this out just 5 months after the release of 0.9.6 in July, my expectation is that we will continue to increase the frequency of releases going forward.
The most user visible difference in 0.9.7 is the reworked Notes and "Bugs" support. This can now work offline and supports, besides OSM Notes, warning and error reports from OSMOSE. One of the nicer aspects is that you can "auto-download" Notes and OSMOSE data (this naturally requires that you are online) independently of OSM data proper and with two "clicks" inspect a report, download the element in question, zoom to its position and select it:
Further the short cut to the "Tag only" editing mode has now been made official (long press on the lock icon) and we have a greatly improved documentation site. For more information see the release notes.
For a long time I've been wanting to produce some numbers detailing the size and growth of our national contributor communities. While a lot of things are sort of assumed to be true for example that the D-A-CH region is by far the largest community we've been missing some hard numbers.
Given the awful weather this weekend I at last had some time to finish off what I had started on a couple of weeks back.
So that you can play around with the numbers yourself and have a look at what interests you I've dumped the output in to a LibreOffice spreadsheet.
Some interesting things that I produced for myself:
The above graph shows new contributors per month for the US and Germany, it clearly shows that the adoption of OpenStreetMap in Germany was very strong early on in the projects life and has essentially continued at that level since 2008. The US on the other hand has a completely different history with the growth rates picking up substantially in 2014. It should be noted that the US is nearly three times more populous than Germany so the US is still adopting substantially slower than Germany at this point in time.
Naturally inquiring minds want to know which community is the largest, no surprise there, it is Germany at nearly double the size of the runner up. But a large population, which is one of the major drivers for the absolute size, is naturally not an achievement. So lets have a look at the contributor number per head:
Again no surprise Austria leads the pack. Note this is a bit unfair in that Vatican City actually has 4 contributors per 1000 population and a couple of the other very small states have higher numbers too, but cutting off at half a million population seems to be reasonably sensible.
Finally how are our contributors distributed over the world:
Two thirds of all contributors are in Europe, again no surprise.
Methodology and Caveats (lots of them)
The numbers are generated from geo-coded (country level) changesets and are current as of September 2015. For each changeset the centroid was determined and that compared to a set of OSM derived country boundaries. Of the roughly 35 million changesets 2 million didn't return a result, aka the centroid was not located in a country (likely over water). The first non-HOT or Missing Maps changeset was used to determine which country a mapper belongs to. Filtering out the identifiable HOT and Missing Maps changesets reduced the overall count of contributors by 8000.
- using the location of the first changeset is naturally a very rough indicator of where a mapper is located and further it naturally doesn't take migration in any form in to account.
- along borders using the bounding box centroid will potentially lead to miscounts
- very large bounding boxes will cause miscounts
- 6000 accounts couldn't be associated with a country at all (aka the initial changeset was in the 2 million that couldn’t be geo-referenced)
- prior to the use of hashtags by the HOT community it wasn't possible to filter out such changesets, as a result the contributor number in targets of HOT activations prior to 2013 should be taken with large grains of salt
- country borders tend to be a bit volatile and you can argue a lot about which continent certain countries belong to.
It is a truism that software has bugs and while as a developer it would be nice to say that they are all somebodies else's fault, but we are probably are all just as bad as each other with respect to slip-ups. In the case of Vespucci the additional complication is that we are dealing with at least 26 different Android versions and 100s of different devices, each with its own manufacturer tweaks to hard- and software.
So unluckily now and then you might experience a crash. I do have to say outside of provoked crashes and early dev builds I haven't had one for ages, but then I use a relative mainstream device for mapping and don't try to edit gigantic areas, The important thing is to either get the issue fixed, or at least find out how to avoid it in the future.
Those readers that have had the unpleasant experience know that post-crash you will be offered the chance to submit a crash report. We do this with ACRA http://www.acra.ch/ and store the reports on a private acralyser server. ACRA gives us a lot of information on the HW and SW configuration of the device, a short excerpt of the system logfile and a stacktrace indicating what the immediate cause of the crash was and where in the Vespucci or Android code it happened. It does not store any personal information of the user in question, in principle we could ask for an e-mail address, but I would prefer not to for data protection reasons. Note on the side: there are some situations in which we'll produce a stack trace just to document an unusual situation, if you don't get an additional warning in general there is no reason to be concerned.
Now if you experienced a real crash (real: as in Vespucci restarted or stopped completely) please submit the crash report, but further please check our issue tracker and our twitter account. If your problem doesn't seem to be known or not already fixed, please open a new issue pointing out that you submitted a report, this is the only way we can get in direct contact with you. Complaining on googles play store or continuously sending the same crash (don't forget it might be related to your device or your editing habits) wont help.
No, this is not news. Vespucci has had a tag-only mode since its original creation in 2009, however since the old very modal user interface hasn't been the default UI after the work by Jan Schejbal in 2012 and the start of the 0.9 releases, it hasn't really been easily accessible.
Starting with 0.9.6 tag editing only mode can be switched on with a long press on the lock icon.
vespucci can still be locked/unlocked with a normal single touch on the lock and a long touch will get you back to normal editing mode.
Now while I personally don't quite see the utility of such a mode, users have asked for it and it is the only remains of the old modes that will survive in 0.9.7. In any case it is light years better than the many apps of different kinds that claim to offer simple editing but in general are survey apps on steroids that mess up existing data.
I'll be missing this weeks hack weekend in London with the topic of "mobile development", unluckily it turned out to be on the one weekend this year on which I really coudn't find a way to attend. In any case I wanted to at least give an update on how far I've progressed with the work on vespucci 0.9.7 which is scheduled for release early in Q4.
From a development perspective I try to get stuff that involves major internal changes done as early as possible in the ramp up to a release, for the obvious reason that we then have enough time to find issues in completely new code.
For 0.9.7 the big refactoring has been in the Notes code which in prior versions has been online only (you needed to have a working network connection and any changes to the Notes had to be committed immediately). I've reworked the whole subsystem to work more like the way vespucci handles OSM data: you can download Notes for an area manually or using a auto-download setting, work on them, save them locally for uploading at home or upload them immediately. And on top of that the same mechanisms support Osmose bug reports.
A further long time enhancement suggestions by our users was to support translated presets, for both technical and licence reasons we can't fall back on the work that has already been done for JOSM (vespucci uses JOSM format presets) and I ended up doing it rather different way and using the GNU gettext format for holding the translated strings (there is a long and boring story why the Android i8n system can't be used). The other preset related thing requested was a search function, which with the translated presets will work with those languages too.
As you can see the search seems to be a bit too fuzzy right now and will need some further tuning (some of the fuzziness is due to searching both in the original preset names and translated ones).
Back to the hack weekend and more interesting stuff. The current build of 0.9.7 contains substantially better support for generating notifications (on your phone and on any attached android wear devices, see my last diary entry) and includes support for Osmose bugs. This is fine where I live but in high error regions will potentially swamp you with notifications, some of this can be avoided by filtering the Osmose bugs, but some kind of distance vs. seriousness filter would likely work best.
The other hot topic is voice support: the current build has an experimental "pure voice" interface that IMHO doesn't really make a lot of sense and goes against the basic philosophy of vespucci that you should nearly never need to fix data after entering it on the road. What seems to work far better is a hybrid approach that I've built: mark the position where you want the new object (as always in vespucci with a long press) and then use a voice command to actually select what you want to add.
Press the microphone:
This works better than expected, particularly for names that are in the name suggestion index. Naturally likely one reason this works well is because googles voice recognition works better with well known name and terms.
If you want to play around with the current build (and please: feedback is welcome), as always it is located on google drive
Now that 0.9.6 is out, my focus is, naturally, on the next version. Hopefully 0.9.7 wont take quite as long to be ready, I'm fairly optimistic that we will be able to hit the planned release time frame of end of September. The larger operations on the guts of the app have already happened and should have enough time to stabilize till then.
If you are interested in what is planned see https://github.com/MarcusWolschon/osmeditor4android/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.9.7 Two of the items have already progressed pretty far: putting the code in place for translating the presets and the integration of notification support.
The later was mainly written as a proof of concept early this year at the Karlsruhe hack weekend but needed some work to be really useful. Some images from Karlsruhe:
Alert on a watch (naturally works on phone too) from an error detected in the nearby OSM data
the same for a Note
and navigating to the location with OSMand
A test build with the inital (still needs a bit or work for production) alert support is available here: https://drive.google.com/folderview?id=0B9pKLmh8s1h8bFI5bGd4VnhYWkk&usp=sharing . You will need to turn on alert support in the advanced preferences and have "auto download" enabled in the GPS menu (if auto-download doesn't initially work try toggling the setting).
While I have your attention: one of the work items is redoing the Notes code to work more like the rest of Vespucci and allow offline use. Are there any specific wishes for how it should behave (I will likely leave a way to immediately save and close a note in the app, but the normal mode will be a bulk upload at the end of your surveying/editing session). If you have some suggestions please add them to: https://github.com/MarcusWolschon/osmeditor4android/issues/228
In case you didn't notice we have pushed 0.9.6 to the regular google play store. Release notes can be found on device and in the repository. There is likely to be a small maintenance release soon that will address a handful of minor issues.
If you do experience an issue or even a crash, please submit the crash dump if any and check our issue tracker for known issues and if appropriate open a new one. Vespucci supports a large number of different devices over a wide range of Android versions (2..2 to 5.1.1) and the issue you are expierencing maybe not be repeatable on other devices or circumstances. A post on the google play store does not get problems resolved.
In all the noise about MapBox's Series B offering and their successful bid to replace MapQuest's in house map rendering capability, it seems that our dear trade rags missed something.
Likely the most important medium term aspect of the successful bid is that it removed funding and support for a competing vector tile rendering stack that MQ was developing internally.
Anybody that has been following the developments knows that while open source and in principle freely available, the MapBox vector tile stack doesn't work "out of the box" in any reasonable meaning of the words. It follows the trend of the bits and pieces of MapBox's technology becoming increasingly more difficult to use in practice by the community. The other well known example is MapBox studio, the follow up to the widely independently used TileMill.
A recent article actually points to parts that are closed source, a not completly unexpected change of direction.
Now I think we all realize that it is just a matter of time till the open source community catches up on the vector tile front. This will address some of the issues the OSM community has been having with its map rendering and even the playing field a bit. But MapBox has clearly bought themselves some more breathing space for now.