前几天一位朋友问我手头有一批规划坐标图层零零总总一千多个shp文件字段命名五花八门dbf里的中文编码还不统一要全部落到同一套Oracle空间库里怎么处理比较稳。我的第一个建议是先别急着写JDBC循环插入先把一个图层转成一批SQL语句拿小样本跑通再放开全量。这个流程看着绕路实际上在批量空间数据入库的场景里是最不容易翻车的做法之一。这篇就围绕这个思路把Java读取shapefile、拼装SDO_GEOMETRY、生成SQL脚本最后在Oracle里建表建索引的完整流程拆开讲一遍。适合这几类人看刚接手空间数据入库需求的Java后端同学、专职做GIS数据清洗的工程师、需要审核入库方案的DBA以及正在纠结“到底用JDBC还是转SQL”的项目负责人。1. 为什么是“转SQL”而不是JDBC直连入库1.1 三种入库方式的取舍遇到这种需求很多人的第一反应是写Java代码读shp然后JDBC一条条insert进去。这当然能跑但实际项目里我并不优先选它。下面把常见的三种方式放在一起对比你能更清楚看到各自的边界。入库方式优点缺点最适合的场景JDBC直连批处理插入编程直接、实时性好错误可以在代码里catch数据转换和传输耦合脚本不易留档大批量中断恢复麻烦应用系统实时写空间数据、增量同步生成SQL脚本再导入可审计、可回放、DBA可评审出错可在脚本里修改不占用应用连接多一个执行步骤超大脚本需拆分会话执行历史数据归档、跨系统迁移、批量地图入库Oracle SQL*Loader性能极高适合纯属性数据对SDO_GEOMETRY嵌套结构不友好通常要落临时表再转换控制文件复杂海量表格型数据、没有复杂几何的批量导入生成SQL脚本这个方案等于在中间加了一道看得见的工序。脚本可以交给DBA评审可以记录数据血缘可以随时重跑单个文件也能在异常发生时直接跳到出错的那一行修改后再执行。对批量历史数据归档来说这些特点比执行速度重要得多。Oracle还有一个官方工具SQL*Loader性能确实高但对SDO_GEOMETRY这种嵌套结构支持不算友好。通常的做法是先导成一张临时表再用存储过程把坐标转换几何绕的圈子更长。如果目标表只是普通关系型字段还能考虑现在表里带空间列我更愿意让每个要素都变成一行可读的INSERT。1.2 这个方案适合谁、不适合谁适合一次性或周期性的数据整理。比如把甲系统的历史图层迁到乙系统把分散在个人机器上的shp统一收进底图库这种任务优先选择转SQL。原因是它们几乎都是“一次性搬家”需要过程可控、结果可复核而不是追求毫秒级入库。反过来如果业务是实时写入比如轨迹点不间断落库、订单地址实时写空间列那就得用JDBC直连或消息队列不能退化成生成脚本再执行。生成SQL脚本本质上是一种“离线批处理”的思路实时链路里加一个文件中转环节反而画蛇添足。还有一个边界要注意当数据量到千万级要素时SQL脚本文件会变得非常大sqlplus执行和回滚都不方便。这种场景建议改用时序批量程序或分区导入但这是另一个话题。大部分GIS业务图层在几十万要素以内转SQL绰绰有余。2. 动手前要搞懂的Shapefile底层三件套2.1 一个图层其实是三个文件很多人第一次接触shapefile以为就是一个文件。其实一个完整的图层至少由三个文件组成.shp保存几何坐标.shx是空间索引文件.dbf保存属性数据。复制文件时只拿.shpdbf没有属性全部丢失只拿shp和dbf没有shx不少读库工具也能重建索引但如果要对原始文件做随机访问shx仍然很重要。因此迁移文件时三个主文件一定要一起拷。文件本身是二进制格式。.shp文件开始是100字节的文件头记录了版本、文件长度、shape类型以及整个图层的包围盒之后每条记录由8字节的记录头和不定长的记录内容组成。.dbf则是一个很古老的dBASE格式每一行记录是定长的。了解这些底层结构不是为了让你手写二进制解析器而是为了排查问题时知道该往哪里看——比如遇到坐标乱掉先怀疑.shp解析问题遇到属性对不上先怀疑.dbf字段顺序问题。dbf的字段名长度一般被限制在10个字符左右字段类型只有字符型、数字型、日期型、逻辑型等几种中文属性经常需要GBK或UTF-8编码才能正常读取。所以数据入库往往不是简单复制字段而是先做一个字段映射。2.2 几何类型编号与坐标系来源shapefile的几何类型用数字表示0表示空几何1是点3是折线5是多边形8是多点。带Z值的类型是11、13、15带测量值的类型是21、23、25。Oracle的SDO_GTYPE虽然也编号但规则不一样前面两位加维度后面两位是几何类型2001是二维点、2002是二维线、2003是二维多边形、2005是二维多点、2006是二维多线、2007是二维多多边形。所以从shp读到要素之后不能直接把shapefile的类型码填进SDO_GEOMETRY必须先转换成SDO_GTYPE这是转换里最容易错的一步。shapefile几何类型码含义通常对应的SDO_GTYPE1Point20013PolyLine20025Polygon单个外环20035Polygon多个外环20078MultiPoint2005坐标系统的来源主要是.prj文件里面是一段WKT文本记录了投影方式。.cpg文件则声明了dbf字符编码。读取shp时优先使用这两个文件里的声明没有prj文件时转换工具里要能手工指定坐标系。我见过很多图层拿过来时没有坐标系入库后所有图层叠不到一起最后返工这就是源头没处理好的典型。3. Java端读取与转换核心实现3.1 工具库选型Java生态里读shapefile最省事的是开源GIS工具库GeoTools。它能直接把.shp、.dbf、.prj解析成一个要素数据源我只需要关心怎么遍历要素。如果你的项目不允许引入重量级依赖也可以自写解析但复杂多边形、带孔多边形、带Z值的几何处理起来会很痛苦尤其是要和SDO_GEOMETRY的SDO_ELEM_INFO数组对齐的时候。我建议多数项目直接用GeoTools。依赖文件虽然大但它处理杂牌数据的能力非常强。项目里引入依赖的方式很简单核心的gt-shapefile模块就够了。如果还要在Java侧做坐标转换需要额外引入gt-referencing和相关EPSG数据模块。不要学我第一次直接引入一个聚合模块依赖膨胀编译时间肉眼可见变长。dependency groupIdorg.geotools/groupId artifactIdgt-shapefile/artifactId version28.2/version /dependency版本号可以用当前稳定发行版代替这里只是示例。另外务必注意GeoTools的模块依赖可能会拉入一堆第三方包模块之间如果版本不一致很容易出现NoSuchMethodError。经验是固定一个整体版本不要只升级某一个模块。3.2 dbf编码与中文读取Shapefile时第一个动作是设置字符集。dbf本身没有统一的编码声明旁边的.cpg文件可能会写比如65001表示UTF-8936表示GBK。如果.cpg不存在就按源数据的实际经验来设置。GeoTools里读取前调用store.setCharset(Charset.forName(GBK))如果dbf实际是UTF-8就设置UTF-8。这个顺序搞反中文属性在Java里就已经是乱码后续生成的SQL脚本里自然全是问号。用Java读dbf时还要注意字段值的类型。比如数字字段在dbf里可能存的是空字符串而不是数值NULL字符串字段也可能有不可见的前后空格。SQL脚本生成时这些细节会影响目标表的完整性。我的做法是在代码里统一做一次类型搬移读出来是空串的字符字段输出NULL数字字段解析失败也输出NULL避免把脏数据带进Oracle。3.3 几何坐标提取与SQL拼装拿到一个SimpleFeature之后默认几何属性一般是the_geom类型是JTS的Geometry。接下来要把它转换成SDO_GEOMETRY需要确定三件事几何类型、SRID、坐标串。这里给一个最小可运行的遍历逻辑示例。import org.geotools.data.FileDataStore; import org.geotools.data.FileDataStoreFinder; import org.geotools.data.simple.SimpleFeatureIterator; import org.geotools.data.simple.SimpleFeatureSource; import org.locationtech.jts.geom.Geometry; import org.opengis.feature.simple.SimpleFeature; FileDataStore store FileDataStoreFinder.getDataStore(shapeFile); store.setCharset(java.nio.charset.Charset.forName(GBK)); SimpleFeatureSource source store.getFeatureSource(store.getTypeNames()[0]); BufferedWriter writer Files.newBufferedWriter(Paths.get(output.sql), StandardCharsets.UTF_8); try (SimpleFeatureIterator it source.getFeatures().features()) { while (it.hasNext()) { SimpleFeature f it.next(); Object id f.getAttribute(OBJECT_ID); String name (String) f.getAttribute(NAME); Geometry geom (Geometry) f.getDefaultGeometry(); if (geom null || geom.isEmpty()) { continue; } String ordinates buildOrdinates(geom); String sql buildInsertSql(id, name, geom.getGeometryType(), ordinates); writer.write(sql); } } finally { writer.close(); store.dispose(); }buildOrdinates负责把JTS几何的顶点坐标按顺序输出成x,y,x,y的平铺串。这里直接用geom.getCoordinates()注意这个方法会把多部件、带孔的几何内部顶点全部取出来顺序是JTS内部定义好的一般不需要自己再遍历子要素。简单实现如下。private static String buildOrdinates(Geometry geom) { StringBuilder sb new StringBuilder(); for (Coordinate c : geom.getCoordinates()) { if (sb.length() 0) { sb.append(,); } sb.append(c.x).append(,).append(c.y); } return sb.toString(); }buildInsertSql则把属性值和几何构造函数拼成一条完整的SQL。这里为了控制复杂度先处理最简单的单外环Polygon其他几何类型在后面的章节单独说。private static String buildInsertSql(Object id, String name, String geometryType, String ordinates) { // 根据geometryType映射SDO_GTYPEPoint-2001LineString-2002Polygon-2003 int gtype guessSdoGtype(geometryType); // Oracle字符串中单引号需要翻倍 String safeName String.valueOf(name).replace(, ); return INSERT INTO LAND_PARCEL (ID, CODE, NAME, GEOM) VALUES ( id , safeName , SDO_GEOMETRY( gtype , 4326, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1), SDO_ORDINATE_ARRAY( ordinates )));\n; }最终生成的SQL长这样INSERT INTO LAND_PARCEL (ID, CODE, NAME, GEOM) VALUES (1, A001, 测试地块, SDO_GEOMETRY(2003, 4326, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1), SDO_ORDINATE_ARRAY(116.2,39.3,116.3,39.3,116.3,39.4,116.2,39.4,116.2,39.3)));这里SDO_ELEM_INFO_ARRAY的三个数字含义是坐标数组从第1个数字开始1003表示二维外环多边形1表示这个环是简单闭合的。点要素的情况完全不一样点的SDO_ELEM_INFO_ARRAY应该写成(1,1,1)不要照着面去套。3.4 生成SQL脚本的几个工程细节生成文件时我坚持每条INSERT独立成一行不搞INSERT ALL。INSERT ALL看着省事但定位错误特别痛苦。每个输出文件的前几行放一组sqlplus控制命令比如SET DEFINE OFF、SET ECHO OFF、SET FEEDBACK 1。每1万条左右插一个COMMIT;这样脚本执行过程中如果中断已经提交的部分不会全部回滚。脚本文件建议保存为UTF-8但这里有个容易忽视的点如果你在SQL脚本里写中文注释而执行脚本的sqlplus客户端字符集和文件编码不一致sqlplus可能在解析注释时出怪问题。我的习惯是生成脚本时干脆不放中文注释字段名和表名都用大写避免编辑器保存编码不一致把整个脚本带进奇怪状态。还有字段值里的单引号问题。Oracle里字符串的单引号转义方式是写两个单引号所以生成SQL时一定要做replace(, )。遇到值里有回车换行符时我一般会更早处理要么去掉要么转换成CHR(10)拼接否则SQL脚本里混入回车会导致语法错乱排查起来非常费劲。4. Oracle Spatial落地建表、SDO_GEOMETRY与空间索引4.1 SDO_GEOMETRY的两种写法第一种是标准构造函数SDO_GEOMETRY(gtype, srid, null, sdoElemInfoArray, sdoOrdinateArray)适合点、简单线、简单面。第二种是用SDO_UTIL.FROM_WKTGEOMETRY直接喂WKT文本适合复杂多边形、带孔多边形、多部件几何。两种写法的SQL分别如下-- 构造式 INSERT INTO LAND_PARCEL (ID, CODE, NAME, GEOM) VALUES (1, A001, 测试地块, SDO_GEOMETRY(2003, 4326, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1), SDO_ORDINATE_ARRAY(116.2,39.3,116.3,39.3,116.3,39.4,116.2,39.4,116.2,39.3))); -- WKT式 INSERT INTO LAND_PARCEL (ID, CODE, NAME, GEOM) VALUES (1, A001, 测试地块, SDO_UTIL.FROM_WKTGEOMETRY(POLYGON ((116.2 39.3, 116.3 39.3, 116.3 39.4, 116.2 39.4, 116.2 39.3))));使用WKT方式时有个大坑WKT里坐标对之间只能用空格不能用逗号。比如POINT (116.2 39.3)是对的写成POINT (116.2, 39.3)就会报错。这个错误很隐蔽因为看起来完全合理。如果你要处理的图层以简单点、线、面为主构造式足够一旦几何里出现多个外环、内环、MultiPolygon我强烈建议Java端生成WKT字符串用SDO_UTIL.FROM_WKTGEOMETRY入库。这样能把SDO_ELEM_INFO数组的复杂计算甩给Oracle自己处理出错概率大幅下降。4.2 建表、空间元数据与空间索引建表DDL并不复杂空间列类型写MDSYS.SDO_GEOMETRY或直接写SDO_GEOMETRY都可以。给几何列加NOT NULL约束是个好习惯能挡住一部分空几何。CREATE TABLE LAND_PARCEL ( ID NUMBER(10) NOT NULL, CODE VARCHAR2(32), NAME VARCHAR2(256), GEOM MDSYS.SDO_GEOMETRY );接下来最关键的一步往USER_SDO_GEOM_METADATA表里插入空间元数据。如果漏掉这一步后面创建空间索引会失败即便索引能建立空间查询性能也和全表扫描差不多。INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES ( LAND_PARCEL, GEOM, SDO_DIM_ARRAY( SDO_DIM_ELEMENT(X, -180, 180, 0.00005), SDO_DIM_ELEMENT(Y, -90, 90, 0.00005) ), 4326 );DIMINFO里的范围一定要覆盖全量数据的坐标范围。如果是经纬度坐标系容差给0.00005度如果是投影坐标系容差给0.05米或0.001米具体看数据精度。元数据插入之后再创建空间索引CREATE INDEX IDX_LAND_PARCEL_GEOM ON LAND_PARCEL(GEOM) INDEXTYPE IS MDSYS.SPATIAL_INDEX;数据量特别大时可以加PARALLEL 4并行但我不建议一开始就这么干。先单线程把索引建起来如果失败排查范围更小。4.3 导入后的快速验证全量导完别立刻宣布成功先跑几条统计命令看看。SELECT COUNT(*), COUNT(GEOM) FROM LAND_PARCEL; SELECT ID, SDO_UTIL.TO_GEOJSON(GEOM) FROM LAND_PARCEL WHERE GEOM IS NOT NULL AND ROWNUM 5; SELECT SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(GEOM, 0.00005) VALID, COUNT(*) FROM LAND_PARCEL GROUP BY SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(GEOM, 0.00005);第二条如果输出GeoJSON坐标出现几千几万的值或者经纬度明显颠倒说明坐标顺序或坐标系理解有误。第三条如果校验结果出现不是TRUE的情况需要根据Oracle返回的错误码逐类排查。这一步虽然简单但能挡住后续空间查询里最尴尬的“数据在就是查不对”问题。5. 常见问题排查与避坑实录5.1 dbf中文乱码最典型的症状是打开生成的SQL脚本中文全是问号插进Oracle后SELECT出来还是问号。排查顺序是先看Java控制台输出是不是中文。如果Java侧已经是乱码说明dbf读取字符集设置错了如果Java侧正确再看SQL脚本文件保存字符集最后看sqlplus客户端字符集。90%的问题在第一步。一个小技巧用十六进制工具打开dbf看字段值的原始字节。中文GBK通常是两个字节UTF-8通常是三个字节。根据这个规律可以反推编码不用完全依赖.cpg文件。这也是为什么我建议大家把“读取字符集”做成配置项而不是写死在代码里。5.2 几何类型与空间索引报错这类报错在批量导入时特别常见我整理了几个高频场景。报错原因解决思路ORA-00932: inconsistent datatypesINSERT语句里几何列的位置写错或字符串直接放进了SDO_GEOMETRY位置检查列顺序确保SDO_GEOMETRY构造函数完整ORA-29875 / 空间索引操作失败USER_SDO_GEOM_METADATA没插元数据或SRID不一致补齐元数据检查DIMINFO范围ORA-13349: polygon boundary is not closed多边形首尾点不重合在WKT或坐标串里让首尾坐标相同ORA-13356: adjacent points are duplicates相邻点重复或坐标里有NaN清洗geometry坐标后再生成SQL还有一个经常踩的坑点要素的SDO_ELEM_INFO_ARRAY写成了(1,1003,1)。点是点面是面点要素应该用(1,1,1)不要因为复制了面的模板就把坐标类型一起带过去。5.3 带孔多边形与复合要素如果图斑里有岛洞构造式SDO_ELEM_INFO真的容易算错。一个带内环的多边形SDO_ELEM_INFO数组需要同时描述外环和内环外环用1003内环用2003后面还要用offset标出内环在坐标数组中的起始位置。这个offset是SDO_ORDINATE_ARRAY里从1开始计数随便错一位几何就废了。我实际项目里遇到复杂要素一律改用WKT方式。用JTS的Geometry.toText()方法直接生成WKT字符串然后套上SDO_UTIL.FROM_WKTGEOMETRY复杂多边形的内外环关系由Oracle自己解析省心得多。SDO_UTIL.FROM_WKTGEOMETRY支持POLYGON、MULTIPOLYGON、LINESTRING、MULTILINESTRING、POINT、MULTIPOINT覆盖shapefile绝大多数场景而且SDO_GTYPE由Oracle自己计算不用人工填。5.4 脚本执行环节的幺蛾子sqlplus里跑脚本第一件事是执行SET DEFINE OFF。否则SQL里出现符会被当成变量占位符好好的INSERT变成另一句话。另外sqlplus并不是出现一条红字就会停下来很多时候它会继续跑后面的所以批量执行时一定要看着每个文件末尾的提交条数或者用日志重定向把全部回显保存下来。大批量执行时建议把脚本拆成2万行一个文件每个文件末尾COMMIT。出错后根据记录ID重跑对应子脚本不会影响已提交的数据。生成脚本时还可以给每一条INSERT加纯数字注释比如/* 102 */定位错误会快很多。注释里不要带中文原因前面说过了。5.5 坐标系SRID别乱填SRID填错是隐性问题不是直接报错所以危害更大。把高斯投影数据填成4326表面上能插进去查距离却差好几倍。正确做法是拿到shp先看.prj用GeoTools打印CoordinateReferenceSystem不知道标准EPSG时宁可先填NULL入库后用SDO_CS.TRANSFORM统一转换。如果要做坐标转换我建议在Java阶段用GeoTools的MathTransform把几何转到WGS84后再生成SQL这样SQL脚本里SRID固定4326后续统一。不要一个脚本里多种SRID混着写Oracle空间索引对混合SRID的图层管理很麻烦查起来也会出现各种匪夷所思的结果。6. 实操之后我留下的几个小习惯最后分享几个我保留了很久的习惯不算秘籍但确实省过不少返工时间。第一写转换程序之前永远先挑一个有代表性的图层。这个图层最好同时包含中文属性、一个带洞多边形、一个多点要素。用这个图层生成50条SQL打印到控制台人工看一眼数据类型和几何构造是否符合预期再放开全量。我在这一步挡掉过至少四五次大返工。第二生成的SQL脚本本身也要留档不要只保留数据库里的结果。数据来源、字段映射、坐标系版本都写进一个manifest文件。时间久了你就知道这个优势——三个月后有人问“这批数据怎么来的”直接把文件翻出来就行不用再靠回忆。第三转换程序统一输出日志到文件出错时打印要素ID、几何类型、出错原因。我见过太多转换程序在循环里catch异常然后默默continue最后数据量对不上找半天不知道哪条丢了。日志里保留要素的标识能让你在十万条数据里几秒钟定位问题。如果你只是想把百十来个shp摊进Oracle底图库这个方案笨但绝不失控。