It’s almost certainly not a problem with OSM at all, rather the problem is the IP geolocation database Facebook/Instagram are using.
Sadly as they make themselves impossible to contact their users see our names on the map and flood our support channels with their complaint instead.
The reason docker fails is that there is no init at all when using kitchen-docket so chef (having found there is no systemd running) assumes upstart is the init and then fails to find /sbin/status and errors.
As I explained on the github ticket, this is why we use vagrant, so that we have full VMs with a running init where we can manage services.
I am working on trying to use containers, but with a running init, and I have many of our tests working now, though with podman and I haven’t tried with real docker yet.
Please accept my apologies for my total incompetence.
I have immediately pushed an urgent update to re-enable indexing of diary entries and I beg that will accept my most grovelling apology.
Wasn’t it you that suggested blocking indexing of the diary pages as a temporary measure? Certainly it’s something we can revisit now.
As to why we don’t allow the geodata to be indexed it’s because of the load hundreds of searching engines crawling billions of objects puts on our servers.
Please contact email@example.com
Nobody has refused to remove anything - the report was still in the queue for review.
It has now been dealt with.
See https://github.com/gravitystorm/blogs.osm.org/issues/17 but the short version is that there’s no real way to do it because RSS doesn’t have a way to publish a removal request and the aggregator only looks for new posts and takes existing posts from it’s cache.
The only way to do it would be to remove the aggregator’s cache before every run and rebuild everything completely from scratch which would mean it would not keep any history.
I’ll tell you how not to do it - by posting spam on third party sites!
No OSM sysadmin is going to assist a random user with access to potentially personal data like IP addresses.
If there is a problem then report it to DWG and they will be able to make whatever enquiries are necessary and to seek assistance of the admins where necessary.
It is completely untrue that Nominatim doesn’t search relations - the first result for https://nominatim.openstreetmap.org/search.php?q=Broxbourne is https://nominatim.openstreetmap.org/details.php?place_id=198582074 which is, as the page clearly says, a result for https://www.openstreetmap.org/relation/2677978.
The problem is that you want us to presume guilt on the basis of no evidence other than your hunch and I say we will only act where there is reasonable evidence.
Let me be clear - we will not be closing accounts just because you think they might spam at some point in the future, and posting a diary entry that is simply “odd” or “not useful” does not constitute spam under any sane definition that I am aware of.
By your own logic (of not being relevant to OSM) this diary entry is, in fact, spam.
How many times do I have to tell you that “not useful” is not the same as “spam”.
If you’re referring to the map data then it appears that both the place node the the boundary relation have name=India in english and name:hi=भारत which I think is the word you’re talking about - that is clearly the Hindi name though and there are many other name tags in other languages and you can of course add more.
Could you explain where exactly you are seeing this?
I can’t imagine that it appears anywhere in the user interface text, and even if it does then it would presumably only do so when you had the Hindi language selected and if you selected a different Indian language then you would (assuming somebody had done the relevant translation) see a more appropriate phrase.
Just for the record I don’t think the Red Cross donation was kept secret as such, it’s just that the intention was to announce it was the machine it bought was installed and doing it’s job and we in operations were a bit slow getting that done and it sat around for some months after initial installation and testing before we got it live.
Once it was live I believe the blog post happened more or less immediately.
Obviously the donation could just have been announced and then the machine later but I genuinely don’t think there was anything underhand - it was just thought easier to do everything at once and then that took a lot longer than intended.
I don’t think Andy pulls in data directly from Sustrans - he just uses whatever data is in the main OSM database.
So if we’re out of date then fix it and it should show up on the cycle layer - just be careful of any license issues if using Sustrans as a source rather than surveying on the ground.
Adding ele tags to existing objects (if accurate, which GPS elevations rarely are) is certainly not terrible but equally probably isn’t that valuable.
Trying to create an elevation model by adding a grid of nodes just to carry ele tags would be pretty terrible.