-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are non-US County-level political subdivisions geography? #5109
Comments
I'm not sure what to do here, neither San Quintín nor San Felipe are in GADM or geoBoundaries (so they must share data or a source?). @mkoo any magic? |
I think the municipalities in general are not a sustainable precedent in
HG. Can it not be accommodated in spec_loc?
HG I think needs to firmly require a spatial footprint (at least we're
trying) and municipalities in any country are not super stable and not
reliably in GADM. Exceptions occur of course since US counties are used in
permitting and more or less stable.
Now having said that, we have some for others in Arctos for Baja. But for
those two:
wiki says:
"The municipalities of San Quintín and San Felipe have since been
incorporated from territories previously belonging to Ensenada and
Mexicali."
Is Arctos HG upto date on GADM? If so can verbatim and spec localities
reflect these deprecated admin boundaries?
…On Wed, Sep 28, 2022 at 1:47 PM dustymc ***@***.***> wrote:
I'm not sure what to do here, neither San Quintín nor San Felipe are in
GADM or geoBoundaries (so they must share data or a source?). @mkoo
<https://github.com/mkoo> any magic?
—
Reply to this email directly, view it on GitHub
<#5109 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AATH7UJNS4MC7A7KBSBUFS3WASVGBANCNFSM6AAAAAAQYCTJ7M>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Amen!
I've explored a relatively minor part of the world in some detail from a spatial standpoint recently, and this is a huge understatement. (And I probably don't have the resolution to notice when borders are quietly re-drawn; I'm sure my perspective is still very lacking.)
It's getting there, bits and pieces are, overall there's a VERY long way to go. (And some sort of AWG-ish blessing/rejection of #5076 would help; I've been trying to walk the razors edge between not making the messes messier and not blocking users, not that much fun really.)
One consideration might be how things like geolocate handle various data. County (and island) in specloc seem about the same as in county to me, but I'm usually looking at the weird data that's fell out of something else so IDK how far that holds. I do suspect I'd see a HUGE functional difference if we had....
6.5K fewer things - or 65% of everything at the moment - to choose from. Some significant portion of our geography errors seem to from users not internalizing the whole thing (which can be far from trivial when it's a little of this and a dash of that and...), there are usability benefits to simplicity. And I just moved a bunch of "but it says county!" state-level things to where they belong, being more restrictive with county might or might not help on that front. From a completely opposite perspective, we do have the option to add dates to former geography at this point, things that aren't current could be added if necessary. Those don't generally have spatial data just because I don't like impossible tasks, and I hope everyone will eventually migrate to modern (or let Arctos take care of it - including georeferencing) but IDK how realistic that is. |
Losing the ability to make the municipalities in Mexico "normal" seems terrible from a discoverability perspective. There will end up being a million ways to spell San Quintin in spec loc and nobody will ever find all of the things from there if that is what they are interested in. I feel like we are being given a devil's bargain - get the shapes but lose a lot of controlled vocabulary. Maybe I am missing something in all of this, but I kinda don't like it. |
That's the beauty of sharing the locality table though! We can fix,
people can find, curators can use 'em
And remember San Quintin municipio no longer exists to MX. So maybe an
attribute...?
This has been basically our working protocol BTW, for admn_2 in non-US
countries for a while, so not making this up on the fly
…On Wed, Sep 28, 2022 at 5:43 PM Teresa Mayfield-Meyer < ***@***.***> wrote:
Losing the ability to make the municipalities in Mexico "normal" seems
terrible from a discoverability perspective. There will end up being a
million ways to spell San Quintin in spec loc and nobody will ever find all
of the things from there if that is what they are interested in.
I feel like we are being given a devil's bargain - get the shapes but lose
a lot of controlled vocabulary. Maybe I am missing something in all of
this, but I kinda don't like it.
—
Reply to this email directly, view it on GitHub
<#5109 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AATH7UJDI3WBMYHH6YLYYW3WATQ3JANCNFSM6AAAAAAQYCTJ7M>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Whose? I don't think this has been a community protocol because lots of munis and other level 2 localities were being created up until this new "must have spatial" requirement. I'm not saying it is wrong, but it isn't what everyone is doing as far as I can tell and it really sucks when the one you need isn't there, but a bunch of others are - how do we tell incoming collections that theirs isn't "worth" it?
Can we? I need a tutorial. - #5116
I don't think we can keep up with "current" geography over the long term. This is a huge global issue, but within Arctos, we just cannot do it and all of the legacy data that shows up is potentially going to have "political divisions that no longer exist". I spend a lot of time trying to figure out what higher geography should get used for some of this stuff and it's not fun. It sucks to have stuff like this hold up bulkloading. Sorry for the rant, but we don't really have a well-documented plan for higher geography and it's making me crazy. |
I don't think we're looking at that the same way. There's are a TON - thousands - of things that aren't in any way geography treated as geography, because until now it's just all strings and nobody can tell 'local name for county, country' from some actual county from some actual county that hasn't existed since 1874 and is nowhere near the modern city of the same name (and infinite variations on all those). The spatial data does lots of things, but a primary function is linking the string to a real, nonimaginary, semirecent place.
I've proposed lots of things over the years, one that keeps coming back up is moving "curatorially-asserted geography" much more verbatim-ward (that could be a string or have any amount of structure, details are irrelevant at this point) and letting Arctos assert actual geography. (And I don't see any way that would result in anything other than an easier time in a simpler environment for humans, and data which can't conflict with itself as the computers get involved - maybe that's just a lack of imagination...)
Yep. Can we convene some emergency meeting to flesh that out, or refuse to talk about anything else at the normal meetings until we have a solution, or come up with some sort of a plan that might lead to a plan for the plan?? |
Convenient example: I just deleted Kenya, Kakagmega - looks like a bad spelling of Kenya, Kakamega (that's what I assumed for the deletion, anyway). That sort of thing is inevitable when people are typing, impossible when we're pulling from existing sources. EDIT: and Kenya, Taita Taveta/Kenya, Taita-Taveta, and Kenya, Trans Nzoia/Kenya, Tran- Nzoia ugh.... |
Yes please! I see it's on the agenda for this week's issues meeting to talk about a more organized Geography Committee, which is a good step forward |
Hijacking the rest of this, discussion should focus on #5109 (comment)
|
Merge-->#5138 |
First Step: Explain what geography needs created.
San Quintín Municipality is not included in Arctos, but the other munis of Baja California are. This is needed for CSULB data migration.
We will respond with a CSV template, or request more information.
The text was updated successfully, but these errors were encountered: