誰もがSQLiteを好みます。これは単一のポータブルファイルであり、パフォーマンスとスケーラビリティに優れ、十分に役立つSQLをサポートし、DB-API<\/A>準拠のPythonモジュールおよび他の言語でのAPIアクセスがあります。多くのモバイルおよびデスクトップアプリに組み込まれており、ArcGIS Proで直接使用可能です。<\/P><\/P>SQLiteはコンテナとしての形態を持ち、それがOGC GeoPackageです。これはArcGIS Proで直接使用するためのベクターおよびラスター特徴のエンコーディングをサポートしています。標準についてはOGCのウェブサイト<\/A>でご覧いただけます。<\/P><\/P>GeoPackageと最もよく比較されるGISフォーマットはEsri定義のshapefileです。Shapefileは世界で最も共有されているGISフォーマットで、そのベクター特徴のエンコーディングは公開されています<\/A>。ただし公開日は1998年です。当時shapefileが設計された際には、利用可能なコンポーネントに制限があり、今日の高度なワークフローでは不便な点があります。これにはファイルサイズ制限、属性フィールド数と名前幅の制限、時間をサポートしない日付、文字エンコーディング処理の複雑さ、およびほとんどのフィールドタイプでnull値サポートがないことが含まれます。Shapefileは単純なベクター特徴の取り扱いに非常に成功しましたが、制限もあります。<\/P><\/P>私はGeoPackageを古い制限なしの新しいshapefileと考えており、使用をお勧めします。それは素晴らしいgeo-packaging用フォーマットです！しかし、それが完全なGISワークスペースだとは考えないでください。ドメインや属性ルールなどジオデータベースの動作はありません。できることはしっかり行います。<\/P><\/P>GeoPackageは拡張可能で、高度データのグリッドタイルやテーブル関係のための承認済みOGC拡張、および特徴のマップスタイリングやベクタタイル保存など非承認コミュニティ拡張があります。ArcGIS ProはまだGeoPackage拡張（v1.2リリースで採用されたテーブル機能<\/A>を除く）をサポートしていません。<\/P><\/P><\/P>ArcGIS Pro 2.6でGeoPackageで何ができますか？<\/P><\/P>単純特徴（ポリゴン、ポリライン、ポイント、マルチポイント、円弧、テーブル）の読み書き<\/LI>Feature Class to Feature Classツールでフィーチャクラス作成<\/LI>Table to Tableツールでテーブル作成<\/LI>カタログペインでコピー／ペースト使用<\/LI>Appendツールで既存フィーチャクラスまたはテーブルにデータ追加<\/LI>Add Raster To Geopackageツールで画像保存<\/LI>編集の元に戻す・やり直し機能付きで特徴や行を編集<\/LI>スキーマ変更<\/LI>単純フィーチャクラスまたはテーブルを入力とする任意のジオプロセシングツールを使用可能<\/LI>ArcGIS Online内の静的アイテムとしてGeoPackageデータを他ユーザーと共有可能<\/LI>地図ワークフローでGeoPackageベクターおよびラスター データ使用可能<\/LI>Data Interoperability ETLワークフローでGeoPackage読み書き可能<\/LI>SQLiteネイティブ方言によるSQL文使用可能<\/LI><\/UL><\/P>ArcGIS Pro 2.6でGeoPackageでは何ができませんか？(できないこと)<\/<EM>GeoPackageアイテムをホスト型Webレイヤーとして公開することメタデータの保存または編集ジオデータベース出力を必要とするジオプロセシングツールの使用いくつかの推奨事項：フィールド追加や値計算はジオプロセシングツールやArcPyで可能ですが、ネイティブジオデータベース操作より遅い場合があります。GeoPackage内のジオメトリ保存はジオデータベースほど圧縮されていないため、大きくなることがあります。ジオプロセシングはGeoPackage作成前に行い、その後データをコピーしてください。GeoPackageは共有フォーマットとして考えてください。データをGeoPackageに移動する方法：Create SQLite Database (GeoPackage空間タイプ使用)<\/<STRONG>ツールでGeoPackage作成Copyツール（Data Management, Generalツールセット）またはカタログペイン内コピー／ペーストでベクターデータ追加Add Raster to GeoPackageツール（Conversion, To GeoPackageツールセット）でラスター モザイク追加これでGeoPackageが使用準備完了です。共有についての注意：.gpkgファイルをArcGIS Onlineにアップロードするとファイルタイプが認識されます。アイテム共有後リンクを送信すれば他者がコンテンツギャラリーからダウンロード可能です。高度な話題：SQLiteベースなのでGeoPackageにはデータベースエンジンと優れたSQL言語<\/<A>>サポートがあります。SQLite用サードパーティーツールもありますが、空間コンポーネントを含めるにはArcGIS Data InteroperabilityまたはSafe Software FME製品がSELECT, CREATE, DROP, DUPLICATE, TRUNCATE, CROSS JOIN文をSpatial ETLツールトランスフォーマー（SQLCreatorやSQLExecutorなど）内でスクリプト化してサポートします。この方法により非常に強力かつ高性能なGeoPackage利用が可能になります。
<\/P>
SQLiteはコンテナとしての形態を持ち、それがOGC GeoPackageです。これはArcGIS Proで直接使用するためのベクターおよびラスター特徴のエンコーディングをサポートしています。標準については
GeoPackageと最もよく比較されるGISフォーマットはEsri定義のshapefileです。Shapefileは世界で最も共有されているGISフォーマットで、そのベクター特徴のエンコーディングは
私はGeoPackageを古い制限なしの新しいshapefileと考えており、使用をお勧めします。それは素晴らしいgeo-packaging用フォーマットです！しかし、それが完全なGISワークスペースだとは考えないでください。ドメインや属性ルールなどジオデータベースの動作はありません。できることはしっかり行います。<\/P>
GeoPackageは拡張可能で、高度データのグリッドタイルやテーブル関係のための承認済みOGC拡張、および特徴のマップスタイリングやベクタタイル保存など非承認コミュニティ拡張があります。ArcGIS ProはまだGeoPackage拡張（v1.2リリースで採用された
ArcGIS Pro 2.6でGeoPackageで何ができますか？<\/P>
ArcGIS Pro 2.6でGeoPackageでは何ができませんか？(できないこと)<\/<EM>
いくつかの推奨事項：フィールド追加や値計算はジオプロセシングツールやArcPyで可能ですが、ネイティブジオデータベース操作より遅い場合があります。GeoPackage内のジオメトリ保存はジオデータベースほど圧縮されていないため、大きくなることがあります。ジオプロセシングはGeoPackage作成前に行い、その後データをコピーしてください。GeoPackageは共有フォーマットとして考えてください。
データをGeoPackageに移動する方法：
これでGeoPackageが使用準備完了です。
共有についての注意：.gpkgファイルをArcGIS Onlineにアップロードするとファイルタイプが認識されます。アイテム共有後リンクを送信すれば他者がコンテンツギャラリーからダウンロード可能です。
高度な話題：SQLiteベースなのでGeoPackageにはデータベースエンジンと優れた
I have a solution where the field is redefined in the geopackage before uploading. A second version allows for non UTC datetime.
import pandas as pd def normalise_date_fields(gdf, use_utc: bool = True, local_tz=None, verbose: bool = True): """ Convert epoch-based date fields to timezone-aware datetimes. Targets columns with 'date' or 'time' in the name. Parameters ---------- gdf : GeoDataFrame Input GeoDataFrame. use_utc : bool, default True If True, output datetimes are in UTC (tz-aware, +00:00). If False, output datetimes are converted to local timezone (tz-aware with offset). local_tz : str | tzinfo | None Timezone to use when use_utc=False. - None => use the machine's local timezone. - str => e.g. "Pacific/Auckland" verbose : bool Print conversion messages. Returns ------- GeoDataFrame GeoDataFrame with converted datetime columns where applicable. """ # Resolve local timezone (only used when use_utc=False) if not use_utc: if local_tz is None: # Use the runtime environment's local timezone local_tz = pd.Timestamp.now().tz_localize("UTC").tz_convert(None).tzinfo # Note: tz_convert(None) returns naive; tzinfo can still be recovered in many envs, # but if your environment behaves oddly, pass local_tz="Pacific/Auckland". elif isinstance(local_tz, str): # Pandas can use IANA tz database strings local_tz = local_tz # else assume tzinfo-like object is passed through for col in gdf.columns: col_lc = col.lower() if "date" in col_lc or "time" in col_lc: series = gdf[col] # Only attempt conversion on numeric columns if pd.api.types.is_numeric_dtype(series): max_val = series.dropna().max() # Heuristic: epoch milliseconds are usually > 1e12 if pd.notna(max_val) and max_val > 1e12: try: # Step 1: interpret epoch(ms) as UTC dt_utc = pd.to_datetime(series, unit="ms", utc=True, errors="coerce") # Step 2: optionally convert to local timezone (keeping offset) if use_utc: gdf[col] = dt_utc if verbose: print(f" ✓ Converted epoch(ms) → datetime (UTC): {col}") else: gdf[col] = dt_utc.dt.tz_convert(local_tz) if verbose: print(f" ✓ Converted epoch(ms) → datetime (local offset): {col} ({local_tz})") except Exception as e: if verbose: print(f" ⚠ Failed to convert {col}: {e}") return gdf # -------- main ----------- # other processing... gdf = gpd.GeoDataFrame.from_features(features) gdf = gdf.set_crs("EPSG:4326") gdf = normalise_date_fields(gdf) gdf.to_file(GPKG_PATH, layer=layer, driver="GPKG") print(f" Saved: {layer} ({len(gdf)} features)")
@ChrisLeSueur Question for you above.
I am having trouble with date fields in a geopackage. The best format is an ISO string because it can include the timezone. But it can be an epoch number. Sqlite handles all dates as functions, not a data type. This means that AGOL cannot read a date in a geopackage. How does Survey123 handle dates in a geopackage?
The GIS format most often compared with GeoPackage is the Esri-defined shapefile.
I have not seen GeoPackage compared to a shapefile. GeoPackage is more of an up-and-coming competitor to the File Geodatabase. While GeoPackage is still somewhat immature as a standard (in terms of implementation... QGIS being further along in its implementation), some of the limitations are ArcGIS Pro limitations (editing) while others are inherent to the leaner core spec (domains and subtypes).
However, don't go as far as thinking it is a full-blown GIS workspace
Not to be pedantic! but..
<SPAN class="keyword token">import</SPAN> arcpy gpkg <SPAN class="operator token">=</SPAN> r<SPAN class="string token">"C:\Data\db.gpkg"</SPAN> desc <SPAN class="operator token">=</SPAN> arcpy<SPAN class="punctuation token">.</SPAN>Describe<SPAN class="punctuation token">(</SPAN>gpkg<SPAN class="punctuation token">)</SPAN> <SPAN class="keyword token">if</SPAN> hasattr<SPAN class="punctuation token">(</SPAN>desc<SPAN class="punctuation token">,</SPAN> <SPAN class="string token">'dataType'</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">:</SPAN> <SPAN class="keyword token">print</SPAN><SPAN class="punctuation token">(</SPAN>desc<SPAN class="punctuation token">.</SPAN>dataType<SPAN class="punctuation token">)</SPAN> <SPAN class="operator token">>></SPAN>Workspace<SPAN class="line-numbers-rows"><SPAN></SPAN><SPAN></SPAN><SPAN></SPAN><SPAN></SPAN><SPAN></SPAN><SPAN></SPAN><SPAN></SPAN><SPAN></SPAN><SPAN></SPAN></SPAN>
Think of GeoPackage as a sharing format
Eh, not really unless a geospatial professional never, ever, ever leaves the Esri reservation for anything, ever (which is not good for anyone). It should be pointed out that GeoPackage offers some very important efficiencies over the File Geodatabase. For example GeoPackage supports views, which means that you can quickly return results through SQL statements without having to create new data. i.e. you can do this
buffer<SPAN class="punctuation token">(</SPAN>geom<SPAN class="punctuation token">,</SPAN> <SPAN class="number token">1000</SPAN><SPAN class="punctuation token">)</SPAN> <SPAN class="keyword token">as</SPAN> geom<SPAN class="line-numbers-rows"><SPAN></SPAN></SPAN>
instead of having to run a Buffer tool and place an output somewhere. Used properly, this can eclipse the expand issue brought up in the article and offer a considerable performance advantage over the legacy FGDB container.
That said, I use both formats for processing and it all depends on the use case. Generally if I need to process a big table of data and I know I can achieve the result through SQL, I will do it in GPKG. If I need to daisy chain together a set of ArcGIS tools to get a result, I'll go with File Geodatabase and do as much intermediate processing as possible in memory.
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
