While looking for instances of adding menu items to the context menu, I noticed the Look up with Map Service context menu for Place views. My Map Service was defaulted to OpenStreetMaps
When trying this for a “Boston, Suffolk, Massachusetts, United States” hierarchical place, it linked to a malformed URL: https://nominatim.openstreetmap.org/ui/search.php.html?q=Boston,+Suffolk,+Massachusetts,+United+States
Changing the search.php.html to search.html makes the URL work. (Eliminating both extensions also works.)
Where can this code be found to hack?:
The docs in the wiki for this feature are rudimentary. Since services frequently change their URL and parameter passing format, features like this (and the Web Connections) probably need a hackers guide. Or maybe be changed to use an external CSV file or GUI editable config table.
That the offending .php is removed in 5.2 is great.
But such map services are likely to suffer linkrot since the services have to change frequently. They have to reduce the number of people (or robots) using such testbeds for batch production work.
Gramps has enough interface in the way that we don’t put a big load on them. But the linkrot is probable anyway… as a consequence of their combating the abusers.
We could use an example of converting a feature to store these perishable items in a CSV in a folder of the User Directory. And a tool for editing that table inside Gramps.
That would be nice indeed, because the web connections are a mess anyway, especially when you install different versions. They are nice to get French, English, and German sites, but I really don’t care about having French, English, and German Googles.
It surprised me that external links are not all in a central configuration file. With due respect to the developers here, I understood that it was not a good programming technique to hardcode anything that could change.
I strongly agree that there should be one place to store all external links.
These sorts of things are an evolution. Features tend to be hard-coded until a reason arises making them adjustable. That always requires adding error-handling. Then another enough reason arises to invest the effort to build an interface.
In this case, there might be enough reusability potential to make a reusable module for Gramps.
The multiple OS support makes validating a filepath (which might include a local hard drive, removable storage or a network location; or a URI/URL) quite a challenge.
An enhancement that that been discussed for 5.3 of the new Addon Manager’s “Projects” would be some validation feedback for a ‘good’ path. This feature already has the ability to extend the list, to enable/disable paths without deleting them, and the ability to edit named targets.
It seems like making this URL ‘selector’ reusable would be the next logical step.
And maybe adding a built-in option to toggle between URL and local path selector would be good too. Having to figure out that the local filepath needs to be prepended with a file:/// (with 3 slashes) instead of http:// or https:// is a bit confusing. Plus, the Local Media Path and Backup Path can be browsed to set the path. That’s a lot more foolproof than typing (or pasting-then-editing) a path.
New map services can be created using the addon process. I suppose that existing services could all be made addons so that they could be easily updated when the service changes its URL parameters. OpenStreetMaps dropping the .php parameter is the first change that I am aware of over many years and Gramps versions.
But that raises the issue of some users never adding available addons. The functionality would be lost to them. Does Gramps make certain addons mandatory?
As another open-source project, OpenStreetMaps would probably be the goto option.
I had been having no luck getting openstreetmap to recognize and lookup Boston, Suffolk Co, Massachusetts when no Lat/Lon coordinates where part of its Gramps record.
I just found the problem. OSM did not like the “, U.S.A.” that I use as the country entry. It does like “, USA”.
I had to fix the URL for Open Street mapping for the Narrated Web to work in 5.1.5 and 5.1.6. Does anyone know if this got fixed in 5.2. I think it was in the “report” file.
I think you are confusing two different mapping activities.
My… “It’s fixed in Gramps5.2 beta!” was referring to the blank maps that were appearing in the Narrative Web because of the “latest” versus specific vision release in the openlayers tools. It did not get fixed in 5.1.6 even though it was identified in 5.1.5.
As to the mapping service from the place view list, that is working in 5.2 for the OpenStreetMap service when there is no GPS in the Gramps’ place record. As I pointed out, it does not like my use of “U.S.A.” as a country entry.
The service that hosts my family website logs redirections. The reports of where those originate help me identify patterns of abuse. And I can use that to design changes.
And on the user side, some anti-malware tools monitor for redirection results. And some browser plugins or settings can let the user suppress suspicious redirections.
On the other hand, some rewriting is expected for masking access vulnerabilities.
Are we able to monitor some sort of Failed Request Monitoring to see status codes?
Redirection results might be an early warning sign of linkrot.
It looks like it’s added automatically somewhere down the line. In my original fix, I replaced .php with .html, and that resulted in a double .html in Firefox, so I removed it right away.