Hi Colin

If I had had my wits about me earlier I would have sent you a message directly. However, by the time that I connected ‘csmale’ with ‘The Maarssen Mapper’ I had completely forgotten about that issue. It has only ever affected me with that one file although, of course, there are a whole panoply of ascii characters to need to encode.

Re-reading this entry has also reminded me that there might be another issue with those lines affected by my ignorance, to which I’ll make a Coda.

Hi @Andrzej31

The chap was about my age (66) and obtained it whilst on holiday there. He pronounced it “ken-ya”, but it is likely that his father and/or grandfather would have pronounced it “keen-ya” (I got that info from reading Joyce Grenville).

Because this is your query, and not mine. There are other things (mapping + diary entries) that I put my time into.

Hmm, quick follow-up having read the thread to date on ‘as-in’. As I suspected, even the Nominatim folks do not know how their program works. Good stuff.

That first is an excellent link, DaveF, and is food for thought - thank you. Where is the source-code referred to, please? I’m going to need to see that before I switch (my personal experience tells me otherwise, so I need to discover where I was wrong). I’ve tried to find the source find it in the past & could not after ages of searching.

Regarding the second link I’ll stop using ref:hectare immediately (not that I’ve done any areas for a little while, now). I respect Andy’s work & opinion totally.

Many, many thanks for taking the time to set this out for me (and all others that read this).

Hi DaveF

You ask: “Where does it say Nominatum uses is_in rather than boundaries?”
My reply: Absolutely nowhere, DaveF; no-one has used the phrase ‘rather than’; that would be foolish.

It has been my experience, across the 6 months that I’ve been mapping, that Nominatum makes use of some *is_in** values within admin_level=10 BoundaryLines whilst producing search & location info.

Please recall that there is zero insistence from me that you use any *is_in** values within your mapping. I have personally found that they have assisted search & location info produced from OSM within those parts of the map that I’ve placed such values. Further, my programming + database experience suggests that the resource levels for DB lookups would be minimal cf geospacial mathematics, and thus such an action would make sense within the code. In addition, it should be obvious that humans read maps and can find those values useful. Finally, they produce no harm.

I am not going to deny my personal experience. I will disseminate that experience to anyone willing to listen. If you choose not to listen, that is your prerogative.

You are welcome to deny my assertions by quoting from the Nominatum source, or any of the other utilities used by Nominatum to produce it’s results. If you cannot do so, then please leave me free to carry on my mapping in peace. Thank you.

Hi Dave F

What you say is accurate in itself. However, there are 2 aspects to consider:—

1. Humans are lousy at geospacial mathematics
   For this reason those keys are valuable when a human browses the BoundaryLine
2. geospacial mathematics is resource intensive
   Thus, (in my experience) Nominatum & suchlike use the as_in* keys to show search & location info.

It is because of (2) in particular that I add those keys into every Boundary relation.

Hi @zarl

“nicely illustrated” : ach! sorry zarl, no pictures for a little while. Mapillary has ‘upgraded’ it’s system. It’s better: pictures can be seen full-screen. However, the site has become dog-slow. I thought it better to do some armchair mapping for a while until they fix it. Then the usual English sunshine‘n’showers summer confirmed me in that decision, so I’m working my way through Nottinghamshire making sure that all the civil parishes are properly setup (which is essential to ensure accurate location + searches).

@Warin61: if fully implemented it requires a push-button for each post/comment (“Report as Spam”) + a similar procedure to confirm the report from a Mod/Admin. All known spammers are auto-stopped from Registering (that is the 99.9%) + each Admin-confirmed report puts that spammer into a DB as a known spammer. The amount of human intervention required is minimal compared to the number of attempts.

What I’m about to say is drawn from 12 years of running a website + ~8 years of being a mod on StopForumSpam:

1. Implement a firewall (iptables under Linux) + db-server (I used MySQL)
2. Implement a RBL (IP blacklist) in conjunction with the firewall + server-DB
   (tornevall operates a good one)
   (other RBL also exist)
3. Implement email+usename checks via StopForumSpam (SFS)

The above requires local caching within the DB of remotely-obtained data to prevent undue strain upon the remote servers. RBL checks are via the well-understood DNS TXT mechanism (this is all from memory, so expect some mistakes) whilst SFS provides an API.

The above mechanism stopped ALL bot spam on my site (it was otherwise thousands daily). The only spam that could get through was human-mediated spam, and that was only the first time (worldwide, any SFS-protected site). Once reported to SFS that spammer is in the SFS DB & any site that makes use of SFS is protected.

Hi @Warin61

“I wonder if hairdressers make something on the side recycling the ‘waste’” I believe that they do in India, and that Indian ladies’ luscious locks supply the hair extension market in the west.

Hi @Piskvor

It is fully possible. I’m a Mod at SFS & it operates a crowd-sourced system that stops 99.9% of spammers dead. The human-mediated spammers can usually get through, but only once. The problem is that it will need custom-built changes to the Diary pages, and my time is solid with surveying whilst the sun shines.

@jonwit “needs a few shingles”: it looks that way, doesn’t it? It may be that you are being deceived by the astonishing levels of humidity that are common in this island, with everywhere within at least 70 miles (113km) of the sea. Last week’s 93℉ (34℃) heat has gone & we are currently down to a more-normal 61℉ (16℃) and 77% humidity. That encourages growth of all sorts of odd stuff on the roofs & in the gutters, mostly as a thin film but sometimes as ‘tufts’ (my house is 1883 & the roof was therefore Welsh slate; my next-door neighbour has indeterminate green tufts at the base of most of her slates). The gutters normally get cleaned out, but the roofs rarely do. A contributing factor is last century’s Clean Air act & thus the loss of tons & tons of sulphur from the air. The local concrete & stones now show lichen growth that was unknown in the 1970s.

A little more on GPS Traces:

If you click through my user-page to my traces you will be able to get a pictorial view of what they look like. Clicking on one of the ‘more’ links will give a pictorial time-track of movements.

Hi @asdofindia

You wrote: > Although it does have an option to “record GPS traces” I haven’t explored this yet and do not know what it does.

GPS traces are the only way to map lines (such as roads) and areas (such as houses) in the absence of aerial imagery. Even if you have good satellite imagery, initially I found it a reassurance to see from the trace that I was on the right path. Having said all that, I no longer use the GPS traces at all (although OSMTracker (the App I use) auto-records a trace every second). A secondary value is to be able to look back afterwards & see where you were working at a particular point in time.

I would agree with @Jedrzej Pelka: if you have good Satellite Imagery, then fix the roads before going in the field, and double-check any changes once you are on the ground.

Just in case it may be significant or helpful, here is the GPS info extracted from the JPEG of that Benchmark (IIRC ImageMagick is required to get the identify utility under Linux):

~$ identify -verbose 2016-07-11_13-34-10.jpg | fgrep exif:GPS
    exif:GPSAltitude: 40/1
    exif:GPSAltitudeRef: 0
    exif:GPSDateStamp: 2016:07:11
    exif:GPSInfo: 720
    exif:GPSLatitude: 52/1, 57/1, 592327/10000
    exif:GPSLatitudeRef: N
    exif:GPSLongitude: 1/1, 5/1, 356760/10000
    exif:GPSLongitudeRef: W

Thanks @Warin61 & @andy mackey, useful as always. Since the Wiki advice is NOT to use type=benchmark NOR survey_point:type=benchmark (essentially, avoid type outside relations) I used:

man_made=survey_point
benchmark=yes

Unfortunately, and as you can see from the photo, there is zero reference or altitude information, which reduces it’s utility a lot. Still, you always remember your first, do you not?

Re: Staffordshire Bricks (aka Tamworth Blue Brick):
see the brick porn within Nottingham Suburban Railway, Part 3

Hi @Matt

Gosh, 7 years… well, I’m a youngster of 3 months and I use terracer every day (am using it right now on semi-detached 30s houses in Ivy Grove, Carlton). I like it a lot, naturally think that it could be improved, and am serious about offering to maintain it — I have a couple of decades of programming experience & am recently retired, so have both the time & desire to tackle it.

I’m sure that uberterrace is wonderful, but the difference is that terracer is easily available to every JOSM user via the standard F2 list of plugins, whilst uberterrace is not. If I’m going to devote my time to it — and time, in the end, is the only thing that we all have to offer — then I want to work on something that everyone will be able to use rather than some niche product.

I’m happy simply to be given co-developer access to the source. However, I’ll send you my email address as a message and, if you want to explore letting me breathe life into your baby, we can take it further.

Hi @SomeoneElse
That word “blame” is the key feature here. I tried my hardest with this diary entry to make a simple factual entry, drawn from a statement from a leading developer to my latest bug report:— ‘there is zero point in making a bug-report on a plugin since most plugins are not maintained by the developers’.

Now, there is lots that can be said in response to that fact at the end of the previous paragraph, but when I make a bug-report there is zero blame from me towards the developers about the fact that there is a bug in the program. I’ve done lots & lots of programming, including a little open-source programming, and I know that bugs are part & parcel of programming. However, my experience is that I have received masses & masses of blame for the fact of making these bug reports. In fact, people have gone ballistic about it. And I’m sorry, and I know that it is a pain, but it’s not my fault that the recent changes in JOSM have decreased the viability of the terracer plugin. I’m just reporting that fact. And seriously, if you cannot handle the reports, go and find something else to do, because you really mustn’t be dealing with the public.

I’ll make an offer, and I’m serious about it:
I’ll take over support of the terracer plugin. Give me a username/password (whatever) so that I can administer the source, and perhaps some suggestions to get going. Then leave me to it. I’ll tell you in a week or two if I’m up to it, or not. Then (if I am up to it) at least one plugin will have a maintainer.

Further edits made to the Lagoon, following a call to Severn Trent (they are a remarkably helpful set of people; I even had an engineer call me today following my initial call to see if he could help further). The edits have not yet been uplifted, as there are a mass of houses that I’m adding in Second Avenue & nearby streets following another survey yesterday.

Having planned to possibly survey yet more streets in the locality I went to view it in the map and, godammit!, Flood Lagoon 5805 shows up on the map as a blue-infill area (just as Andy’s did). I checked it using Potlatch and there has been zero changes to my earlier changeset. The fact that it renders now means that all of @BushmanK’s earlier objections become valid, which is most annoying. However, all of that will need to wait until Monday.