aharvey has commented on the following diary entries

Post When Comment
Sharp Turns onto Ramps about 2 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... almost 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 5 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 almost 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... about 6 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 about 6 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 about 6 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 about 6 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 about 6 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 over 6 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 6 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 6 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 almost 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.

changeset comment almost 7 years ago

Thanks for the advice!

I thought about using a separate associatedStreet relation for each street segment. I decided not to do this as I think it creates an unessesary burdon on people who further split up or merge the street segments, who would then need to also adjust these relations. In my view, that person should not have to worry about this.

For the second solution, I'm worried that things are not abstracted very well.
The segments of the street should only be grouped together once (whether that be street, collectedWay, route, multipolygon, etc...). Adding them all as the street role in the associatedStreet relation just uncessarily duplicates this information.

If there was some universally agreed upon way to group objects, then there would only be one object with name=street_name, and I could tie that object into the street role of the associatedStreet.

I hope that makes sense.