Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Geospatial formats: Shapefile / GeoJSON / KML / GPX conversion and GeoTIFF band split

オープン
  • 何か問題がありますか？
#155 コメント 3 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@KAPPI1925 がすでに取り組んでいます。

2026年10月22日 から。

評価

この issue はまだ評価されていません。

説明

enhancement formats

What would you like Filee to do?

Convert common geospatial (GIS) files, in two steps that can ship as separate pull requests:

  1. Vector data: Shapefile (.shp with its .dbf / .prj, or a .zip of them), GeoJSON, KML / KMZ, GPX and CSV (lat/lon columns or WKT) converting to each other. A Shapefile can also be split into several files, for example one output per value of an attribute column.
  2. Rasters: read GeoTIFF (including 16-bit and float bands), save a multi-band raster as one file per band (name_b1.tif, name_b2.tif, …) and the reverse (stack bands), and save a colour-mapped PNG preview.

Why / when would you use it?

I work in geospatial analysis, where these files are exchanged all day, and the usual way to convert them is a large GIS program or a command-line tool. "Drag a Shapefile onto GeoJSON" or "drag a satellite image onto separate bands" fits Filee well. Because of the route planner it would also unlock chains for free, e.g. Shapefile → CSV → XLSX / JSON.

Ideas for how it could work

I'd like to build this myself, following docs/ADDING-A-CONVERTER.md, and I'd rather agree on the shape with you first:

  • In-process C# only, like the 3D models and data engines: no GDAL/QGIS and nothing from PATH. For the vector side I'm considering NetTopologySuite (BSD-3) with its Esri Shapefile and GeoJSON readers, plus small hand-written KML / GPX readers and writers; I'll check each library's license and list it in THIRD-PARTY-NOTICES.md. Tell me if you prefer fewer dependencies and hand-written readers.
  • Rasters need their own TIFF reader. The ImageMagick Q8 build is 8-bit, so a 16-bit or float elevation or satellite band would be clipped. I'd read the TIFF and its GeoTIFF tags directly (or with a small managed TIFF library) and keep the georeferencing in the per-band outputs.
  • One new format category (for example Geo) with its own donut toolbar profile, so geo files don't mix into Data. Is that fine, or would you rather file them under Data / Cad / Image to keep the UI changes small?
  • Options such as "split by attribute" or the band choice would need preset options and a settings migration. I would start without options (one fixed behaviour per preset) and add them in a later PR.
  • Tests use files generated in the test (as the other engine tests do), plus a few tiny hand-made samples; every new UI string goes into all i18n/*.json files.

Planned pull requests, each small and independent:

  1. GeoJSON ↔ KML / KMZ ↔ GPX ↔ CSV
  2. Shapefile read/write (+ split by attribute)
  3. GeoTIFF reading, PNG preview
  4. Band separation and stacking

Does this direction sound right to you, and is there anything you'd change before I start? If a geospatial engine is out of scope for Filee, I'd rather know now.

主要言語
C#
スター
3.6k
フォーク
192
平均マージ
5時間 33分
マージ済み PR（30日）
72

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

KnifeLemon/Filee のほかの issue

KnifeLemon/Filee の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。