A few minor changes, so this is more an update, but with close to full details.

The tools;

• Forward looking 8.3MP/4K dashcam 2FPS.
• Left facing (270 degrees) old Samsung 8MP phone 1FPS. (Out passenger window)
• Left rear facing (225 degs) old Samsung 3.6MP phone 0.6FPS. (Out passenger window)
• The dashcam records audio (my voice) in one minute chunks.
• All photos and audio are geo-referenced to their current location.
• The Garmin navigation GPS has a current OSM based (mkgmap) map, a POI set of OSM FixMe’s.
• I am a permanent road dweller, retired and wandering Australia. For 10 years now.

The methods - Start of day;

• Start a GPS/NMEA (USB via laptop) UBLOX recording function that also flags movement >3kph and <40kph.
• Start an APRS beacon for those that like to track me. (msg me for details)
• Mount/power up the side facing phones and launch their (laptop) 3>40kph recording scripts.
• Power up the dashcam and let its own GPS settle for 2-3 mins. This is also the voice notes recording device.

The methods - Basic drive;

• Open high speed road 70*100kph. Just let it capture doing voice as below.
• Can’t really play music as it can trigger voice events.

The methods - Voiced items;

• Every road surface change paved vs unpaved on route. (incl concrete bridges)
• Any road calming objects (humps and chicanes) and gates on existing roads.
• Any one*way road situations and associated signage.
• Road surface left and right of track (surprising how many are not currently valid)
• Verify road names signs vs Garmin GPS and voice differences. (including missings)
• Verify waterway names signs vs Garmin GPS and voice differences. (including missings)
• Voice any obvious missing public cross etc roads or major private ones. (eg sealed mine roads)
• Voice all bridge names. (if they exist)
• Respond to FixMe’s. (many an unknown water crossing!)
• Voice any obvious informal parking areas (like stockpile/gravel pit areas) plus any formal not showing on GPS.
• Voice any farm/property names/type and if possible address numbers.
• Voice as many town/other objects as possible, priority to Fire, Police, Ambulance, Church, Govt Offices, Post Office & Telstra phones/exchanges, but try to get all shops, parks, recreation grounds, playgrounds, toilets, camp areas, dump points, water points/tanks, fuel stops, rest areas, touristy things, information boards, welcome signs, comms towers, windpumps, large dams etc as possible.

The methods - High density shopping etc areas;

• It’s impossible (and distracting) to voice such detail, so I rely on the side cameras to (say) take 2-4 images per shop front. This is usually done between 20 and 30kph. Especially high detail I’ll go to 5kph for, and less to 40kph. More than 30kph though there is a higher blurring risk, so really only useful for more distant scenes.
• I open and close the powered windows as I drop below 40kph. Yes I could automate that via a ECM/VCU connection along with capturing some interesting data. Have to be able to override on a wet/cold day though!

The methods - End of day;

• The side cameras save their jpgs direct to laptop, so I stop the capture process and launch a single script that processes every image, including EXIF GPS and other data.
• The dashcam has a WiFi connection, so I download the entire days movie capture. I leave the SD card in the camera. Later in that script I extract out jpgs also with GPS EXIF plus the road speed. The road speed (0) is then used to remove all stationary only videos.
• Processing (before upload) takes roughly twice the time of the actual captures. I have to throttle the i5 laptop in hot weather, but generally it runs flat out for 4*5hrs per drive day. The entire system is actually solar powered (with a charge boost when driving) and more efficient if run this way.

The methods - OSM and Mapillary upload;

• I have 2 laptops, so some concurrency of the workflow happens quite regularly. What I do has been mostly covered by previous diary entries so these are only a few extra.
• The stream of side facing camera views are visually checked for any private dwellings or blurs. These won’t be uploaded, but some are used for house numbers entry before being discarded.
• The dashcam images are not uploaded as the Mapillary server will direct process mp4 videos. They and the (non private) side camera images can be uploaded async with any OSM entry. I upload between 8 and 20 GBytes per days travel. This can overheat the cell modem despite a cooling fan, so I may delay uploads for a location with better signal that keeps the mode cooler. The record was a backlog of 150 GBytes in one 12 hr period.
• I mix the side camera views in the one directory, so I can scroll back and forth over the same scene to read around objects in front of information I need for OSM. I would usually remove them from the directory afterwards, but may need to correlate them with dashcam and voice notes. Images removed means work complete, so I can also keep an OSM backlog, sometimes a week old.
• Although I upload the images to Mapillary I rarely if ever use them for OSM (through ID). I try to do OSM entry when the detail is still fresh in mind and it can take a week for them to appear on server. It’s also far easier/faster to enlarge and track them locally.

About the phones as cameras;

• Android phones with USB tethering enabled is much faster than using its WiFi through an AP. Problem is that the device IP is fixed, so only 1 phone per laptop USB. The 2nd phone is via the slower WiFi. Am thinking of combining USB ports (bridging) to the one network interface, but it’s probably not worth the hassle.
• I use the Android App “ipwebcam”. Basically it presents a web server like functionality, so I just “wget” an image as fast as it will respond. I don’t enable or use the phone GPS. The rate does vary somewhat with light level and WiFi congestion. Telstra also has their cell modem/AP firmware configured to power down if there is no cell signal for more than some time (like maybe an hour), so that can break capture.
• The loss of 3G made these phones very useful as web cameras. No SIM installed, but emergency calls might still work. The USB attached phone is in “airplane mode” so no WiFi/cell RF.
• I have an ordinary cell smartphone. It’s boring though.

About the Garmin GPS navigation device;

• I have a custom mkgmap script to update maps whenever I have the need. Minimally every month.
• Using overpass with some text processing and gpsbabel I can add all manner of special POIs as needed for whatever project I may be working on.
• The default POI is all Fix-Me’s with all the associated point or way fields (minus lat/lon) concatenated with spaces removed, so it can best fit on the Garmin screen. They show up as red blobs on the Garmin screen along with an audible alert at 800m.
• Anything is possible with the OSM data and POI’s. One recent set was of roadside parking sites that were missing some required info, ignoring others that were complete.

About the UBLOX GPS unit;

• This is one of the USB dongle things that I have glued to the inside of the upper left windscreen and connected to the laptop via a USB A*A M/F cable.
• At day start I configure it to act as if mobile (the default being to assume it is sitting still and has position dampening applied) and run at 5 positions/sec rather than 1. I have on occasion wanted the best accuracy for road/way alignment, so upload to OSM the combined UBLOX and dashcam GPX’s in both directions as a private trace. All 4 track lines are then very obvious and easy to centre on. I can also look at any image (they are all georeferenced) to check for a reason for an unusual track deviation. (Like giving a truck the entire road!)

About the laptops;

• The capture laptop is quite an old Toshiba i5 with a (replaced) SSD running Debian Bookworm. The 2nd one (used for OSM entry) is the same, but an i7.
• It helps that I was a systems manager in my employment life, so do a lot of coding.
• The scripting and processing has evolved over the years and kind of complex. Well beyond the scope of this diary items entry. It is worth noting though that I also optimise the image contrast and gamma prior to uploading the side cameras, as none of this processing is done on the Mapillary server. It is well worth doing.

About the vehicle;

• A camping fitted out AWD VW Transporter. Grunty diesel.
• Enough antenanas that I am asked if I work for ASIO quite often.
• 480W solar panels and 300AH LifePO4 battery.
• There is a bed, fridge and cooking gear in there somewhere.
• QRG 40m, 30m, 2m APRS only, no voice. (for those that know what that means)

Please feel free to suggest or ask opinions! As I type this I am camped at Captains Flat, not far south of Canberra (Australia’s capital). The entire Mapillary and OSM backlog is cleared so more driving coming up!

Cheers Bob

I have just spent the last 2 months “intensely” making observations around lesser populated areas in WA’s southwest almost solely from the vehicle drivers seat. I then enter that data into OSM ID most afternoons/nights.

The tools;

• Forward looking 8.3MP/4K dashcam 2FPS
• Left facing (270 degrees) old Samsung 8MP phone 0.3FPS
• Left rear facing (225 degs) 1.3MP webcam 1FPS
• The dashcam records audio (my voice) in one minute chunks
• All photos and audio are geo-referenced to their current location
• The Garmin navigation GPS has a current OSM based map, a POI set of all WA stopping places from MRWA and any OSM FixMe’s.

The methods;

Most of the data is by voice prompts that are reviewed afterwards, but a small proportion come from only viewing (mainly) the 270 camera images of shop etc fronts and signs. It is surpising how useful the multiple camera views are.

Voiced items;

• Every road surface change paved vs unpaved on route. (incl concrete bridges)
• Any road calming objects (humps and chicanes) and gates on existing roads
• Any one-way road situations and associated signage.
• Road surface left and right of track (surprising how many are not currently valid)
• Verify road names signs vs Garmin GPS and voice differences. (including missings)
• Verify waterway names signs vs Garmin GPS and voice differences. (including missings)
• Voice any obvious missing public cross etc roads or major private ones (eg sealed mine roads)
• Voice all bridge names (if they exist)
• Respond to FixMe’s (many an unknown water crossing!)
• Respond to any WA stopping places. (The Garmin will show “Parking” if it is already on OSM, so could be ignored)
• Voice any obvious informal parking areas (like stockpile/gravel pit areas) plus any formal not in the MRWA POI’s
• Voice any farm/property names/type
• Voice as many town/other objects as possible, priority to Fire, Police, Ambulance, Post Office & Telstra but try to get all shops, parks, recreation grounds, playgrounds, toilets, camp areas, dump points, water points/tanks, fuel stops, rest areas, touristy things, information boards, welcome signs, comms towers, windpumps, large dams etc as possible.

Other

• The photos (with certain filtering) are also uploaded to Mapillary, but I don’t actually use the current set with ID.
• How I enter/edit is covered in previous diary posts. The basic flow though is to scroll each 1 minute segment of the forward dashcam ONLY at the active audio point. Then use all camera views, the overhead imagery and what I have voiced to edit ID.

I now need a rest and throat/larynx recovery!

I run a Mapillary supplied BlackVue dashcam uploading my take via the mapillary_tools in two “stabs”. The first is usually same day for road speeds segments below 55kph, the second is up to 2-3 months later. This gives town/village streets and remote road intersections/signs coverage first, for other mappers. I am also taking 1FPS rear left (webcam) and right angle left images (Samsung phone) at less than 40kph for immediate geotag, process/upload. (after manually culling privates)

• Waiting for images to appear on the Mapillary site for my own OSM work degrades and reduces the result. For some time I had processed and geotagged locally, so I could scroll through (1FPS) images at the end of every day. Unfortunately the camera doesn’t always capture sufficient detail and scrolling through thousands of images takes time!
• I would use Geeqie (image viewer) and a “side” text file (gpscorrelate -m) of image filenames and lat/lon, then copy/paste these direct to the OSM ID editor search box.

• Some months ago I started talking into the camera whilst driving. Eg street addresses, business names, features in rest areas etc. The effort is about rough cut removing “no data” and being able to find feature add/changes quickly/accurately. My action is now;

• Process/geotag images as before, but also extract a (1 minute) wav file (ffmpeg) from the BlackVue mp4. This has the same file naming standard and thus indirectly geotag references against the associated image(s).
• Move all images and mp4’s that have no movement (speed=0) for an entire 1 minute block out of future processing.
• Run the wav files through a sox bandpass (sinc) filter to reduce road noise.
• Run each wav through sox vad and remove those that have no voice on it. I have also modified certain timing constraints to reduce false detects. (Currently vad -t 12 -l 1000 -L 1000 -h 300 -H 300 -T 1)
• Move the already tagged images in with their one minute block matching wavs.
• The directory now only contains 1 minute blocks of audio/wav and images/jpg of voice only and vehicle moving.
• All of the above steps are launched by a single bash script on the laptop near the BlackVue. I only need connect to the BlackVue WiFi and run it. It starts downloading the camera (curl/wget) and 1-2 hours later the action directory, gpx data and moving mp4’s are ready. This data is rsync’d to another laptop for the OSM processing.

• Whilst the above is running I often do some OSM/ID work on the previous day’s data (2nd laptop) plus action the side camera culling and uploading.

• Have setup 3 plugins (toolbar icons) in Geeqie; Launch the 1 minute wav file in Audacity associated with that image, copy the lat/lon to the clipboard, and move the entire 1 minute band of images and wav out of the active/processing directory.

• Playing/viewing the 60 sec wav in Audacity (via the Geeqie icon) has 5 second tick marks that correlate with the image filename. Eg 20220504_142256_044.jpg will be at the 44 second mark. If there is only one voice peak on the Audacity display I can quickly scroll/roll to it, not having to view intervening images. If the audio track is very dense, like driving past a long row of shops I can pause audio and scroll/roll as needed. Passing vehicles and UHF FM chatter looks very different on the Audacity display, so these can be ignored.

• The side camera files are similarly named so can be viewed for editor input. The raw >40kph take is also available, but is often too wide time spaced or blurred. They do however work very well on shopfront signs. These image files have also been geotagged, so the Geeqie copy lat/lon button also works.

• Clicking on the lat/lon icon puts the current image position onto the clipboard, that then gets pasted to the ID editor search box.
• I would suspect that I could save a further few seconds by URL launching “remote” on the browser, but not yet!
• When I have completed the feature in ID I click on the Geeqie “move” icon and the entire 1 minute image and wav file set vanishes!

And of additional interest.

Voice detection isn’t perfect, but sox vad can be adjusted. Currently I select on sound peaks and get some false detects from the two way radio and passing vehicle slipstreams.

I have a GPS unit in the top left of the windscreen and the (centred) BlackVue creates *.gps files that can be converted to nmea. I can then therefore do a credible street alignment check on OSM by driving up and down, cutting the associated 4 tracks with Viking then combining (gpsbabel) for a OSM private trace upload. It is easy to see any accuracy issues by having so many detailed tracks superimposed.

It appears that gpx files created (gpsbabel) from the BlackVue *gps (nmea) file don’t have complete speed information. I therefore use the nmea data to tag (exiftool) with. As an interesting extra the BlackVue can be GPS unlocked for the first 1-3 minutes, so the second GPS unit nmea data can be used to fill the gap.

I also do a rough cut of the BlackVue mp4’s to remove those where the vehicle was not moving. Handy if I stop for lunch and keep the camera running. I only want to eventually upload mp4’s that have movement.

Always evolving…

Thought it worth posting this.

After much frustration I have come up with what I do regarding amenity=parking and highway=rest_area (plus details) and have been running this way for 6-12 months. This is live data input (my eyeball/camera/recording etc) as I drive through. I think there have been maybe 1200-1400 objects so far!

I have generally adopted a formal vs informal data set. Formal is almost based wholly on site signs and informal on a mix of triggers and interpretations.

This generally only applies to regional places, not so such towns and high population areas.

There are always contentions! I have come across many (other mapper) highway=rest_area objects that are not “my formal”, as I make no allowance for locations that “could be”. Indeed any parking area could be an informal rest area, so are informal ones needed at all? In the end I sometimes use informal=yes or informal=no to clarify.

So looking at the SA and WA govt databases and my limited travels, SA calls everything “rest areas” and their naming system starts “RA”. This is also seen on roads where virtually every stop has a rest area sign at 1km before, followed by a “P” or two. WA calls everything “stopping places” with a plain number designation. It’s almost as if “P” locations in WA are not allowed to be rest areas! There is also a distinct lack of HGV defined “P” in WA where I wonder if trucks actually get stuck in small ones! Of course Qld is quite unfriendly in defining large areas with useful facilities as HGV only, but that’s another story!

The “informals” are basically NHVR Green Dot, Stockpiles/gravel pits and any place that looks like a truck has been parking for a few years! I also map gravel pits that “could be” used for parking.

So onto the process.

MAIN DECISIONS

• A formal sign saying rest area or the usual graphic tree and table; highway=rest_area also implies additional amenity:parking object and sub tags
• A formal blue “P” parking; amenity=parking access=yes (public) hgv=yes if self judged that an HGV will fit and no other HGV signs exist
• A formal blue HGV “P” parking; amenity=parking hgv=designated
• Any formal “no truck signage” hgv=no (ie hgv are prohibited.) access=yes (public)
• Any formal “no car/LV signage” in a dedicated HGV location hgv=designated access=no

Rest area objects are most often nodes only with just the name. No other tags. (except a possible informal as mentioned above) Parking objects contain maximum tag details. A rest/parking area that has multiple signs only usually has two objects, the parking one containing both access=yes and hgv=designated etc A rest area sign implies parking exists within it, but a parking sign does not imply a rest area exist

• Any informal site hgv=yes if that is the current usage or will fit hgv=no if the entry/exit is too tight Then above are also in precedence order. Example - some formal parking areas were formerly NHVR green dot type, so the formal tagging is used with description including prior NHVR status. (unless the green dots are removed…)

INFORMAL vs not tag

• A formal sign, obvious high expenditure and/or listing in a formal (waivered) government database informal=no or no informal tag Road type that routes to is always highway=service, service=parking_aisle and goes through a parking=surface. If parking objects are nodes they are placed on the service road. Alternatively parking=street_side adjacent the existing road. capacity:hgv is NOT used bin=yes or bin=no lit=yes otherwise not tagged name=Formal or anecdoctal name Description=Anything special. Examples may be “Informal turnout, low speed vehicles”, “HGV LV Stopping Bay”, “HGV only Stopping Bay”, “LV only Stopping Bay” - preceded by relevent blue sign

• The NHVR green dot areas informal=nhvr Road type is always highway=track and goes through parking=surface (area or node) In most cases surface=unpaved of both the parking and through road. It is however possible to see asphalt, fine_gravel and so on. Alternatively parking=street_side adjacent the existing road. capacity:hgv=1 (or more) as a judgement of how many moving 25x4m shapes can independently arrive/leave. bin=yes or bin=no description=NHVR informal parking (Green Dot) area

• Stockpile or gravel pits that are or are likely to be used for parking informal=stockpile Road type is always highway=track and goes through parking=surface (area or node) In most cases surface=fine_gravel of both the parking and through road. Alternatively parking=street_side adjacent the existing road. capacity:hgv=1 (or more) as a judgement of how many moving 25x4m shapes can independently arrive/leave. Allow for the piles of dumped gravel reducing that number, the rule of thumb being just one lane width going through bin=yes or bin=no description=Stockpile site with possible use as truck parking area OR Stockpile site with evidence of use as truck parking area OR Stockpile site, possibly too tight for HGV with hgv=no.

• Any other informal places that are or are likely to be used for parking informal=yes In most cases parking=street_side adjacent the existing road is used, else any through road type is always highway=track and goes through parking=surface (area or node) In most cases surface=unpaved of the parking object. capacity:hgv=1 (or more) as a judgement of how many moving 25x4m shapes can independently arrive/leave. description=Anything useful but most often left blank

Other objects at parking areas

• Picnic shelter and if provided bin and lighting
• Picnic tables
• RV dump points
• Toilets with normal iD full details including lit=yes if so. I also enter the rest area etc as name if known.
• When creating parking objects directly on both sides of a road offset them slightly so the left side “comes first” (for navigator routing engines)

14th March 2022

I am now starting to tackle (mainly my own) fixme’s.

Something like a farm gate and station name is not always readable on my imagery, but even after creating a feature and merging in other sources (like overheads), there are information gaps. A fixme is handy, but I need to action them as well!

I ran a simple overpass query for all node and way fixme’s in a boundary box, then exported it to gpx. I initially thought a Viking moving (GPS) map would work well, but the laptop is on the passenger seat away from my driving vision. I ended up (default) converting the gpx to a Garmin poi file with gpsbabel. set to warn at 800m distance . The “name” is displayed if that feature field is populated, else the node/way number. Additionally if one calls up the POI information on the GPS navigating unit the fixme text is displayed.

Basically I just navigate to the nearest fixme POI using the Garmin GPS display/selection tools. (Note that most of my work is in rural/remote areas, not urban)

I can then drive up close to the “problem” with the dash camera and capture for later editing. I also use the audio from the dashcam mp4 which is me talking into it! Each movie and frame are time referenced to the audio, so it is easy to correlate. I can for example read a fine print sign at a distance that the camera doesn’t capture as well.

5th April 2021

As I tour around Australia I both capture street images for Mapillary, plus do online OSM editing. I don’t have a fixed address, so all my work is done mobile.

Mobile Internet access is quite expensive here, so the daily take of between 8 and 20 Gbytes is saved to a portable USB drive and another mapper kindly uploads 500-1500 GBytes for me at a time. This of course can delay online imagery by 3-4 months as I have to mail or take the drive to the upload location.

The same imagery (downrated to 1FPS) I take on a daily basis is locally geo-encoded and viewed at perhaps 10FPS - 8,000-15,000 per day. Those of interest (100-200) I save to a FIFO directory and periodically run a gpscorrelate job to dump lat/lon to a text file. This text file is then used to cut/paste into the OSM ID editor search/location fiel. Each completed image is moved to a “done” directory and the co-ordinate cut from the text file makes it easy to know which is next.

I correlate the overhead Bing/DCS/Mapbox etc view with ground level ones to make map changes.

I tried launching OSM/ID from Viking or the image directly but it always created a new browser instance.