Do we need a PolygonArray or PolygonCollection domain type?
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 30/100
- Issue-Typ
- Feature
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Ruhig
- Tech-Stack
- json
- Bereich
- data
Rechercherichtung
Beginne damit, Issue #202 und die aktuelle MultiPolygon-Interpretation zu lesen, und untersuche anschließend das hier erwähnte Playground-Verhalten. Ermittle, ob PolygonArray oder PolygonCollection für Bereichswerte pro Polygon benötigt wird und ob dies auch PolygonCollectionSeries erfordert. Als erledigt gilt die Aufgabe, wenn für das Domänenmodell und das Playground-Verhalten eine abgestimmte, dokumentierte Richtung festgelegt ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
I think we have agreed (#202) that the interpretation of MultiPolygon should be as a single domain element, with a single associated range value that applies collectively to all the constituent Polygons. (This is currently inconsistent with the Playground, which would need to be fixed.) But this leaves an obvious question - how should we encode a situation where we want to associate different range values with each individual polygon? For example, recording the population of each of the countries of Europe.
Maybe we need a new domain type - perhaps PolygonArray or PolygonCollection? The domain would look structurally similar to a MultiPolygon but the associated range would be different.
This would also imply a need for a PolygonCollectionSeries.
- Vorherrschende Sprache
- HTML
- Sterne
- 15
- Forks
- 9
- Ø Merge
- 6 Std. 1 Min.
- Gemergte PRs (30 T.)
- 3
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus opengeospatial/CoverageJSON
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 45/100
opengeospatial/CoverageJSON#233 ·
-
New CovJson LibraryOffenImplementations
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
opengeospatial/CoverageJSON#229 · 4 Kommentare ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
opengeospatial/CoverageJSON#227 · 3 Kommentare · 1 Reaktion ·
-
V1.1
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
opengeospatial/CoverageJSON#216 · 9 Kommentare · 3 Reaktionen ·
-
V1.1
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100
opengeospatial/CoverageJSON#207 · 3 Kommentare ·
Alle Issues in opengeospatial/CoverageJSON
Ähnliche Issues
-
area/plugin good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
kestra-io/plugin-soda#137 ·
-
check:passed feeds:add
Schwierigkeit 2/5 Unter einer Stunde Anfängerfreundlichkeit 62/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
neurostuff/NiMARE#1181 ·
Maintainer antworten meist innerhalb von 1 Tag
-
[Bug] build_catalog_relation raises 'Macro' object has no attribute 'config' in run-operation (breaks Elementary edr report on dbt-athena 1.11.x)Evtl. vergeben @Minhhnh hat das heute übernommen. Offentriage:product
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
dbt-labs/dbt-adapters#2222 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
Maintainer antworten meist innerhalb von 1 Tag