Screenshots of what you are seeing (instructions for taking a screenshot on computers and mobile devices: https://www.take-a-screenshot.org/):
Description of problem (please provide a set of steps we can use to replicate the issue, and make as many as you need.):
I marked the border in YELLOW. This location is inside Luxembourg, but appears as Belgium.
Step 1:
Of course, foxes don’t need a visa or passport. Not even during CoviD.
Why it matters:
HERE in Luxembourg foxes are protected by law, so I am free to share their territory and hunting trophies
In Belgium, sadly, hunters are free to KILL them.
Step 3:
I have a several month series about 2 WILD fox families and am worried to publish if there is a risk of attracting hunters.
PS same happens with other observations near the border. I have taken toput in a verygeneral 5 km radius if I observe anything in the wildlife reserves close to the border
If you are concerned that people might misuse the information in your observations, you can set geoprivacy to “obscured” or wait to post observations until several months have passed.
I don’t see why it would make a difference from a protection perspective whether iNat lists the observation as being in Belgium or Luxemburg. If someone is intent on using iNat to hunt foxes in Belgium where it is legal, information that foxes are present in the immediate vicinity may be relevant even if the data was recorded in Luxemburg. As you noted, foxes are not bound by human borders, so it is possible that foxes observed in Luxemburg may cross over into Belgium where they are vulnerable. (This is of course true regardless of whether or not you post observations of them.)
It also concerns other species. Here they like to record the presence of certain insects in the country and it is a pity if they appear in the wrong country.
any which way, if the header lists Luxembourg correctly, why does it appear in “Belgian” observations
I’m not suggesting that the accuracy of the borders is irrelevant.
I am also aware that iNat data may be used in national recording schemes (though I don’t know whether those using the data rely on the borders of iNat places to determine whether to include an observation in their records, or whether they use the other criteria like the coordinates of the observation instead).
However, in light of the specific concern you expressed in your original post, I felt it important to point out that it would be a mistake to think that the safety of the foxes would be guaranteed if only the borders were assigned correctly in iNat’s database.
I don’t mean to detract from your question, which is certainly a valid one at a general level, but I’m intrigued that it’s being asked in regard to foxes. In my experience, they are a ubiquitous species in both suburban and countryside environments across pretty much the entirety of Europe. I can’t imagine would-be hunters needing to use tools like iNat to find foxes easily. Or are they rarer in Luxembourg and Belgium than I realise? In my travels, I seem to encounter them regularly from UK to Turkey and everywhere in between.
as i understand it, most of the administrative borders used in iNat came from an old version of the GADM’s administrative boundaries. so unless iNat goes through another process of ingesting boundaries from a new source at some point, i doubt there’s much that can be done in your case.
it looks like the boundaries may just be simplified. i’m not sure if that’s just the way that they came from GADM or if iNat staff did some simplification while ingesting. the reason for simplification of the borders would just be to either reduce the size of the file that stores the boundaries or to increase performance when using the boundaries.
i would guess that GADM’s boundaries were just simplified to begin with though because when i look at USA state boundaries (which were ingested from US Census data), they look fairly precise.
here’s an example of what the iNat boundary for Belgum (in orange) looks like compared to an OpenStreetMap base layer:
for comparison, below is an example of a section of the Texas boundary with Louisiana. notice how much better the iNat boundaries (based on US Census data rather than GADM admin boundaries) coincide with the OSM base map, although you can see even here, there are inconsistencies, such as with that extra little blob east of the lake. the Texas / Louisiana is supposed to be the river there. so if the course of the river changes, i suppose the border would change too? maybe the inconsistency just reflects the different paths of the river at different points in time?
No, borders do not change based on changing rivers. There are all sorts of weird border irregularities between US states along the Mississippi River where the borders were set and haven’t changed as the River has meandered. I presume it’s the same along the Saline between LA and TX.
We have already decided that the relevant boundary between the States of Texas and Louisiana is the geographic middle of Sabine Pass, Sabine Lake, and Sabine River from the mouth of the Sabine in the Gulf of Mexico to the thirty-second degree of north latitude.
i would assume that that means that the boundary changes as the course of the river changes.
every border is governed by different laws though. so the general method used to determine the border in one place may not be how it’s determined in another place.
Correct, borders on iNat are simplified. If they were complex it would place a greater burden on iNat’s infrastructure. So boundaries are not always accurate, especially in areas where the border might be particularly curvy, like along a river. There’s not much we can do about that, unfortunately.
One thing you could do is move the observation’s coordinates a bit so that they’re in iNat’s boundary for Luxembourg and expand the accuracy circle so that it covers the actual location of the observation. Place indexing for “standard” places on iNat is based on the observation’s coordinates.
you can’t directly adjust the Encompassing Places. you can only directly change the coordinates, which would then indirectly affect the Encompassing Places.
But also GADM’s administrative boundaries are just not good quality. I’ve written to them numerous times trying to get inaccurate boundaries fixed, but have never gotten any response (or changes). It seems to be a derelict project. And because their data is all under a custom license that doesn’t allow free redistribution, no one can fork it to fix the problems. I wish there was a good alternative. OpenStreetMap’s boundary data is hit or miss (it’s not their focus) and difficult to extract. If I knew anything about working with map data, I would start a new GitHub repo to specifically collect and share boundary data. How come no one in the open map community has done this? It mystifies me that this doesn’t exist.
This is a really indirect way to imply such a thing as “abundance,” but a region of Belgium (Wallonia) has an open season on foxes year-round while they have a limited open season on other furbearers. That implies to me that the department in charge of wildlife in Wallonia has deemed foxes “particularly abundant.”
There are things to consider, like political corruption and outdated yet untouched laws, but most of the laws and the rationales supporting them are in French, and I don’t speak French.