aharvey has commented on the following diary entries

Post When Comment
New data sources available for Western Australian roads 2 months ago

Shame we didn't get permission to use the speed limit dataset

Based on the waiver we can use any CC BY 4.0 licensed dataset from

My Bicycle setup for Mapillary 5 months ago

I've been corrected at the camera does correct for tilt. But it doesn't expose this vector so that might explain why my masking of the area below the camera has issues when the camera is tilted going around bends.

Stay tuned for my next review the Sony HDR-AS300.

Announcing my candidacy for OSMF Board Elections 2017 6 months ago

Hi David,

A few questions from me.

increase representation from the AU/NZ/South Pacific Region

What do you see as the main issues we face specific to our region? Do you have any details on local matters which you'd like to take higher to the OSMF level?

and indigenous populations worldwide

I'm very interested to hear about your plans, thoughts or ideas on how we can help encourage indigenous populations to map things important to them. On a local level, documents name:mi for Māori names, but we are lacking any documentation around native Australian languages.

What do you see OSMF can help with that we can't do already at a country level?

upcoming challenges of integrating automated mapping with the local-community focus that should always drive OSM contributions

I'm glad to see this on your agenda.

that if anything is taking away, or discouraging, local ownership of the map it is probably not a good idea.

I agreed. The most accurate maps come from the people closest to what they are mapping, both in terms of location and domain knowledge (eg. a sydney taxi driver is going to be able to map taxi points very well) and I think OSM should encourage the people closest to the map objects in both aspects to participate.

My Bicycle setup for Mapillary 8 months ago

The phone mount I used, eventually sheered off from too many bumps in the road, luckily I had it secured via zipties, but just be warned.

My Bicycle setup for Mapillary 9 months ago

@utack I'd like something standalone and reliable, but personally I find the benefits of 360 capture mean I'll sacrifice image quality and reliability of capture which it's easier to find in non 360 cameras.

I guess you'd need two, one for the front and one for the back?

Even without a swapable battery, something like would raise the LG360 and let you run a USB cable to a power bank to keep it going for the whole day. You still need to power you phone though as unfortunately since the LG360 is so unreliable you need to keep the screen on as sometimes it just stops.

Using Strava traces 9 months ago

You can track progress for iD integration at

My Bicycle setup for Mapillary 9 months ago

The other thing I forgot is, the LG360 needs to be connected to your moblie device while in use, which means the camera is wasting power with wifi and bluetooth. You can't just press a button to start capture and then again to stop.

There is no built in gyro so when it rotates your photos are rotate (so won't work well mounted on a helmet).

Sharp Turns onto Ramps 11 months ago

It's all part of the same style (circles included) just add the style WMTS URL like this into JOSM as a WMTS layer.

If you ONLY want the circle and not the basemap as well, you would need to create your own Mapbox style from that style but remove all layers except the circles.

Tile Stitching... over 4 years ago

I also have a similar script in Perl at

It will take a lat/lon and zoom and image width/height download tiles and paste these together into a single map.

But if your script works for you, no reason not to use it!

Key 'Addr' in multiple languages over 6 years ago

One advantage of the associatedStreet relation is because you can just link the addr to an existing street which would have name:en, name:jp, etc.

Getting railway tunnels (almost) right over 6 years ago

Much easier from the driver seat! If you know the exact distance between, for instance the start and end of the tunnel, at least then you can expand or shrink your curve to match the distance (if you survey this on the way using the note tag).

Feel free to invent tags if you want to tag more technical items.

But great to see a fellow local mapper out there.

Some clarifications to the CTs I agreed to... almost 7 years ago

For me, these have at least a CC-BY requirement,

source=nearmap (which I think you think is okay to be licensed ODbL, but I don't think we actually have that permission...)
source_ref=* (extremely minor, so not worth the worry)

Crunch Time almost 7 years ago

Re: JoshD

The nearmap response posted to the mailing lists said:

>All such additions or edits submitted to OSM prior to 17 June 2011 may be held and continue to be used by OSM under the terms in place between OSM and the individual which submitted the addition or edit at the relevant time.

The terms in place between OSM and me at the time of my submission was I was submitting CC-BY-SA data. I cannot go back in time and change that.

I would be very happy to be wrong about this. I would like to place my nearmap derived data under CC0, just like I place the rest of my original surveyed data CC0, but my understanding of the original license from nearmap, and this statement from nearmap is that I must license the data CC-BY-SA, and hence couldn't accept the CTs, and now I can't go back in time and change "the terms in place between OSM and the individual which submitted the addition or edit at the relevant time.", so I cannot change the license under which my nearmap derived edits were made... I'm happy to be wrong about this as I would rather place my data under CC0.

Crunch Time almost 7 years ago

>It is too bad we can no longer use this source but mapping happened before ANY aerial imagery was available and it will continue without nearmap.

Yes that is perfectly valid and okay. You can continue that effort at OSM, but I'm going to continue that effort over at FOSM. I'm choosing FOSM because it allows for a larger set of freely licensed data to be accepted than OSM and it means that ~90% (just a rough guess here) of my edits and others in my area wont be removed (in lure of more accurate and better quality data replacing it).

Crunch Time almost 7 years ago

>They gave us explicit permission to relicense existing contributions under ODbL.
They can't give OSM/OSMF this permission, because of the way they worded their licensed, the contributor is now the copyright holder to that data. All they can do is say to the contributor "you can relicense existing contributions under ODbL if you choose so".

What was said in a post to the mailing list was,

>All such additions or edits submitted to OSM prior to 17 June 2011 may be held and continue to be used by OSM under the terms in place between OSM and the individual which submitted the addition or edit at the relevant time.

The terms in place between OSM and me at the time of submission was I was submitting CC-BY-SA data. I cannot go back in time and change that.

It appears that nearmap would like for people who agreed to the CTs and submitted nearmap derived content to unvoid that agreement (because the user never had the rights to agree to the CTs and upload nearmap derived content).

Crunch Time almost 7 years ago

I found that communication a bit confusing/contradictory.

If nearmap really lets me license nearmap derived data under any license then I license it under CC0...

Regardless since nearmap is still offering the CC-BY-SA licensed for derived data moving forward, I still want to contribute nearmap derived data in the future too.

I see two nice JOSM features comming up about 7 years ago

Thanks. I know I can run the jar from, but for multiple reasons I prefer the Debian version. Some good folks keep the debian packages up to date with the JOSM tested releases, so once these features make it into the tested JOSM, I should see them.

I support the Proposed Relation Collected_Ways_Simple over 7 years ago

Thanks for the comments.

>Just a simple use case:
>A collected_ways relation includes a number of streets. The type on the collection is "unclassified". The type tag of the ways was removed when creating the collection, just some ways have type "tertiary" which overwrites the "unclassified" tag from the relation.

I'm not actually suggesting this. The Simple_Collected_Way relation could be used to join ways making up one street together so you only have to define the name once, not repeated in every way that makes up the street. This is different to joining multiple streets with different names, that is not what I'm advocating.

>Fine this far.
>No someone, not aware of the relation, edits one of the ways and re-adds the "unclassified" tag.

I think editors could provide the user with a warning, providing hints that this already exists in the relation. User interaction design could help make this simpler for the user.

>Still everything is fine.
>Now someone has new survey info and wants to change the type of the whole way from 'unclassified' to 'residential'. He wants to use the new relation to do this, as it promises a simpler way of altering all the sub-ways, keeping the few 'tertiary' roads untouched.
>But wait, although he changed the type of the relation, some ways kept the 'unclassified' tag. Why? Because they have per-way attributes that now overwrite the relation. he still has to check every single way.
>If the answer to this is: Well the editor has to check all the sub-ways and remove those unnecessary tags, than you could also implement the whole edit-helper aspect of the relation into the editor.
>Just my 2cents

I think editors could do the check, and let the user know what is happening. The user can choose to ignore this or not.

>>Editors could probably be changed
>Use of the passive mood is discouraged in this context.
I apologise, English is not my strong subject. I'm not sure what passive mood is.

>Or, we could just do it per way as we do now. Just sayin'.
>One of our strengths is that our data is human-readable and human-writable, mostly without side effects. Complex interactions such as this are asking for trouble IMO.

Yes, we could. But for the reasons such as needing to check every way that makes up a long street when updating the name, etc of that street, and non-repetition of that shared data (ie. the name of the street), I think this Simple_Collected_Way seems to be the way to go.

This is the most simplest form of relation, it is still human-readable and human-writable.

I support the Proposed Relation Collected_Ways_Simple over 7 years ago

Editors could probably be changed to make it even simpler for users. I should think about this and try to bring some ideas to the table in this area.

Currently it takes a user a lot of clicks to update a name of a road/whatever other feature when the name is duplicated among several short ways, as opposed to this name being in one place where it is tied to all the shorter ways.

I agree that simpler is usually better, this is why I like this proposal compared to some of the other suggestions as you can use existing tagging schemes (don't have to specify collection=street/river/stream/rail) and don't have to worry about the role, hence I think it is much simpler.

changeset comment over 7 years ago


If someone wants to add buildings here to they are free to do that. Personally I see more value in the land parcel, so that is what I've added. At least for the area I mapped as far as I am aware street numbers are tied to the block of land not a building, so that is what I mapped them as.

Even though I've tagged these as boundary=cadastre, I'm not really sure what they are called. I've just mapped out where the fences are for different blocks of land.

I don't think I'll be doing much more of this (tracing residential land boundaries) though, it takes a huge amount of time and at the end of the day the accuracy is bad. I wish I had a free source of cadastral boundaries from the government department, that would make things a lot easier.