[OSM-talk] Introducing SwiftAddress, an highly efficient way of collecting housenumbers

[Simon Poole]

Am 24.01.2021 um 00:29 schrieb ndrw:
> Vespucci is a good general purpose mobile editor but there is 
> definitely space for something more specialized and lighter. I've been 
> using Vespucci on a couple occasions and, frankly, it takes far too 
> much time and effort to be used on the go, both due to poor 
> performance and complex workflows. It works well when I am stationary 
> for an extended period of time but not when I'm walking and looking 
> around.
The address adding is really not complex, when I've used it the 
surveying time has been purely determined by my walking speed.
>
> To be fair, my preferred method of collecting addresses is still a 
> bike, a camera and an in-helmet mic. But for walking surveys a tool 
> like SwiftAddress could be useful.
Have you done any QA on your error rates?
>
>> - allows you to directly enter address for upload, aka enter once, no 
>> 2nd pass needed at home
>>
> That's a disadvantage to me. When on the go, I don't want to be 
> bothered with uploads or data correctness. Anything that can be 
> postponed, should be postponed or deferred to a non-mobile tool like 
> jOSM, which is far more comfortable and faster than any mobile app.
>
Except naturally that irl you are substantially slower. House addresses 
are actually the poster child example of why doing things twice doesn't 
make sense.
>> - automatically will download data (so that you don't accidentally 
>> duplicate existing addresses)
>>
> Good, provided it doesn't download all data, only relevant ones. Here, 
> that would be only nodes+ways with addr: tags, buildings/building 
> parts, nodes with shop, amenity tags etc.
There is no way in OSMs data model to know what "only the relevant data" 
is without downloading all of it. Not to mention that your list is too 
short to start with, as you forgot about streets and places, even in an 
optimistic view of things the only bits you probably can really ignore 
are some types of landuse/nature (put they might have place tags) and 
certain bits of infrastructure, aka power lines and railways, and water 
related stuff.
>
>> - can highlight missing tags, for example addresses
>>
> Good
>>
>> - has all the background and overlay layers from ELI available
>>
> When I'm walking around I can already see the "imagery" with my own 
> eyes. Some background (OSM tiles are fine) could be useful for 
> reference but it should be light and/or preloaded ahead of time.
That is incorrect, being on the ground in front of a building that you 
can see both from the ground and on imagery is a game changer (for 
example for placing a combined address/entrance node).
>
>> - has address prediction that will automatically detect odd / even 
>> address schemes and increment and is street side aware
>>
> Good. But only as a way of speeding up entering the house number. If I 
> have to operate the UI I'd prefer not to have this feature and simply 
> pre-populate the entry with the most recently entered value.
Pressing one button is an order of magnitude less work than changing a 
pre-populated text field (which you can naturally still do if necessary).
>>
>> - allows you to configure which address tags should be set on 
>> addresses (this tends to be a question of national preference)
>>
> Postprocessing in jOSM
Wasted double effort.
>>
>> - handles addr:street and addr:place
>>
> Postprocessing in jOSM + perhaps an ability to record an audio note or 
> enter a custom tag as a fallback.
Audio notes are absolutely hopeless and in summary one of slowest ways 
to survey anything (and I've made 100s if not 1000s of them till point I 
gave it up as a very bad idea).
>>
>> - seeds address tags values from existing data
>>
> Postprocessing in jOSM
Wasted double effort.
>>
>> - and many other things like conflict resolution and so on.
>>
> Postprocessing in jOSM
Wasted double effort.
>>
>> All since more than half a decade (actually 7 years).
>>
> It is an impressive list of feature, for sure. Technology development 
> will address some of the above issues (5G, faster CPUs, larger 
> screens) but limitations caused by poor matching of the workflow and 
> the task will remain. During the survey I don't want to stop to 
> operate the app, even for a moment, and I don't want to look at the 
> screen for more than 2s per entry to have time to look around 
> (surveying and staying safe in traffic).
>
You shouldn't be using your phone in traffic regardless of which app is 
running. In any case nobody is stopping you from keeping your current 
surveying practices, people tend to be very married to them, and if you 
are happy then more power to you.

Simon

> -ndrw6
>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20210124/20c90ccd/attachment.sig>