[common] Extend City<T> with country, AdminRegion and type; enrich cities.xml#189
[common] Extend City<T> with country, AdminRegion and type; enrich cities.xml#189comoglu wants to merge 5 commits intoSeisComP:mainfrom
Conversation
Two new options for controlling the map view when an event arrives, applied in priority order: 1. display.lonmin/max/latmin/max (already existing) — if set, the map is anchored to that region on every event popup, regardless of where the event is located. Useful for regional networks monitoring a fixed area (e.g. an scesv alias per region). 2. display.defaultEventRadius — configurable radius in degrees, centred on the event epicentre (mirrors olv.map.event.defaultRadius in scolv). A negative value (default) restores the original automatic behaviour of using the maximum arrival distance capped at 30 degrees. If neither option is set the existing behaviour is fully preserved.
Extends EventEdit to display arrival stations on the Origins tab map, mirroring the existing station display on the Focal Mechanism tab. - Generalize StationLayer constructor to QWidget* and refSymbol to Map::Symbol* so the layer can be reused outside FMMap - Add StationLayer and AnnotationLayer to _originMap in init(), both hidden by default - Add updateOriginStations() to populate stations from arrivals: picks resolved via Pick::Find() with DatabaseQuery fallback (owned by PickPtr), station locations from inventory, distance/azimuth fallback when no pick is available - Stations are colored by arrival time residual using scheme colors - Lines are drawn from the selected origin dot to each station - Layer visibility toggled by the existing F9 Show Stations action
Extends the City<T> template class with three new optional attributes
to carry richer location metadata sourced from GeoNames and Natural Earth:
type — location type, e.g. "city", "town", "village", "suburb"
state — ISO 3166-2 alphabetic subdivision abbreviation, e.g. "NSW", "CA"
Only present for countries that use alphabetic codes.
stateFull — full administrative region name, e.g. "New South Wales"
All three fields are serialized as XML attributes (NAMED_OBJECT),
consistent with the existing countryID and category fields. They default
to empty strings and are fully backwards-compatible — existing cities.xml
files without these attributes parse without error.
This allows applications such as scolv to display type and state
information via SCApp->cities() without requiring a separate supplementary
locations file.
| std::string _countryID; | ||
| double _population; | ||
| std::string _category; | ||
| std::string _type; |
There was a problem hiding this comment.
Wouldn't a type enumeration be a better approach? Is there a defined set of values for type?
| double _population; | ||
| std::string _category; | ||
| std::string _type; | ||
| std::string _state; |
There was a problem hiding this comment.
I think a dedicated class with an abbreviation would be more appropriate. In XML something like:
<state short|abbr|younameit="BRB">Brandenburg</state>
|
I would be interested in how big that will grow. Given all the redundancy of state and type and also country cannot be for free. I haven't checked but maybe there is already a standard out there to describe such administrative information. |
|
15MB |
|
OK, that is not too much of a difference. The schema itself would be something I would like to address. I personally am not a big fan of "stateFull" which is actually "state". Unfortunately I do not have the time right now. |
|
Thanks for the feedback. To address the stateFull naming concern: in the updated implementation I have already replaced both state and stateFull flat strings with a dedicated AdminRegion that has two clear fields — abbr (ISO 3166-2 suffix, like. "NSW") and name (full subdivision name, e.g. "New South Wales"). This serializes as a child element: New South Wales |
|
Updating Cities xml for entire world in one rule is indeed a hard work. |
|
I've shared the enriched cities.xml as a preview. Enriching city types globally with a single rule set is harder than I would expect — GeoNames feature codes are inconsistently applied (e.g. a 1M+ population city classified as PPL → "town" based on natural earth data (shape file)). Before going further, I'd appreciate your direction: Is the type field worth pursuing, or should I drop it ? |
- City<T>: add country() / setCountry() serialised as <country> child element
- City<T>: replace state/stateFull strings with AdminRegion { abbr, name }
serialised as <state abbr="NSW"><name>New South Wales</name></state>
- Document fixed type values: city, town, village, suburb
- Regenerate cities.xml with country names (Natural Earth), admin region
(ISO 3166-2 abbreviation + full name via NE admin1 shapefile), and type
(GeoNames feature codes); 70242 country names, 71654 states, 56860 types
comoglu
changed the title
2 participants
Extends
City<T>with three new fields to enable richer location descriptions in SeisComP applications.Changes
AdminRegionstruct (replaces flatstate/stateFullstrings)A dedicated struct serialised as a child element:
abbr— ISO 3166-2 alphabetic subdivision suffix (e.g.NSW,CA); empty where only numeric codes exist (e.g. Japan, China, Türkiye)name— full subdivision namecountryfieldFull English country name serialised as a
<country>child element:Allows applications to display a human-readable country name without maintaining a separate ISO A2 → name lookup table.
typefieldLocation type derived from GeoNames feature codes. One of (or empty if unknown):
citytownvillagesuburbUpdated
cities.xmlRe-enriched from freely available sources:
countryIDcountryne_10m_admin_0_countries)statene_10m_admin_1_states_provinces(ISO 3166-2 abbreviations)typecities500.txtfeature codesAll fields are optional and additive — existing applications ignoring them are unaffected.
Enrichment tooling
The pipeline script used to produce the enriched
cities.xmlis available athttps://github.com/comoglu/cities-xml-update — allowing operators to add their own cities or re-enrich from updated upstream data.