DfsuBuilder writes a metre quantity for X/Y static items even in geographic projections (disabled block at DfsuBuilder.py:524)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start at mikecore/DfsuBuilder.py:521-528 and inspect the projection helpers already exposed in Projections.py. Reproduce the LONG/LAT case described in the issue, then determine whether the disabled geographic-quantity block was intentional or left behind. Done means the compatibility decision is explicit and the X/Y static-item quantity behavior is verified against that decision.
Written by the indexing model from the issue text.
Description
mikecore/DfsuBuilder.py:521-528 sets the quantity used for the X-coord and Y-coord static items, with the geographic case commented out:
xyQuantity = eumQuantity(eumItem.eumIGeographicalCoordinate, eumUnit.eumUmeter)
# TODO: reenable:
#if (MapProjection.IsValid(self.__dfsProjection.WKTString)):
# if (MapProjection.IsGeographical(self.__dfsProjection.WKTString)):
# xyQuantity = eumQuantity(eumItem.eumILatLong, eumUnit.eumUdegree)
As it stands, every dfsu written by DfsuBuilder gets eumIGeographicalCoordinate in metre for its X/Y static items — including files whose projection is geographic. For a LONG/LAT file the coordinates in those items are degrees, so the recorded unit is wrong: the disabled block is exactly what would have set eumILatLong/eumUdegree instead.
Reproduction: build a dfsu with SetProjection given the LONG/LAT WKT, write it, then read back the X-coord static item and inspect its quantity — it reports metre.
Projections.py already exposes the projection-inspection needed to re-enable this, so the question is whether the block was disabled for a reason (a dependency that was not ported, or a deliberate compatibility choice) or simply left behind. Not fixed here — writing a different quantity into files changes output, and that decision should be explicit.
- Dominant language
- Python
- Stars
- 5
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from DHI/mikecore-python
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
DHI/mikecore-python#49 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
DHI/mikecore-python#54 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
DHI/mikecore-python#52 ·
-
Remaining TODOs in production code: platform notes, licensing questions, and one likely-stale marker Open
Difficulty 5/5 Over a week Newbie friendliness 30/100
DHI/mikecore-python#51 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
DHI/mikecore-python#50 ·
All issues in DHI/mikecore-python
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
anthropics/skills#1811 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
speaches-ai/speaches#678 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
datalayer/mcp-compose#42 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
conda-forge/spacy-feedstock#177 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
UKGovernmentBEIS/inspect_evals#2523 ·