Yes, it should be possible to do this using the GDAL_WMS driver from GDAL. There is even an example at that page that points to another ArcGIS REST instance. However, I have not been able to make the concept work against this particular VBMP server. Against a slew of other ArcGIS servers with global-mercator output, no problem.
I believe I do not have the layer extents properly defined, or the tile levels, because I keep generating TMS requests that the server cannot respond to. Since I'm used to working with Spherical Mercator TMS requests, ones like this for TMS addresses in a local projection don't make much sense to me- http://gismaps.virginia.gov/arcgis2/rest/services/VBMP2006_2007/MapServer/tile/0/83/68.jpg.
Below is the XML file I put together from the Service metadata page - http://gismaps.virginia.gov/arcgis2/rest/services/VBMP2006_2007/MapServer. You may be able to get some assistance in making this work from the GDAL developer forum. Once GDAL can properly access the service, you can point MapServer (the original one) at the XML file and run a WMS service that can reproject the data from EPSG:3698 to EPSG:900913 (or whatever code is now used).
<GDAL_WMS>
<Service name="TMS">
<ServerUrl>http://gismaps.virginia.gov/arcgis2/rest/services/VBMP2006_2007/MapServer/tile/${z}/${y}/${x}.jpg</ServerUrl>
<Layer>VBMP</Layer>
<Format>jpg</Format>
<Version>1.1.1</Version>
</Service>
<DataWindow>
<UpperLeftX>-384269.977874641</UpperLeftX>
<UpperLeftY>476583.633639972</UpperLeftY>
<LowerRightX>404548.778455541</LowerRightX>
<LowerRightY>-48883.4062351487</LowerRightY>
<TileLevel>13</TileLevel>
<TileCountX>1</TileCountX>
<TileCountY>1</TileCountY>
<YOrigin>top</YOrigin>
</DataWindow>
<Projection>EPSG:3968</Projection>
<BlockSizeX>512</BlockSizeX>
<BlockSizeY>512</BlockSizeY>
<BandsCount>3</BandsCount>
<Cache />
</GDAL_WMS>
Good luck.
Introduction
This will likely require significant amount of manually work to detect and remove the duplicated data. When you're detecting and resolving the duplicate data; you'll want both sources to be in the same geo format: shapefile, PostGIS DBs, or as OSM data.
Workflow
The following workflow is based on having both sources of data as OSM before merging and resolving duplicate data.
There's a couple options to convert the data into OSM:
A]
- Convert the shapefile data into OSM however you'd like.
Versions of ogr2ogr released in 2013 or later (version 1.10 or later, IIRC) can also convert SHP to OSM. There's also
ogr2osm as you had noted: there's a couple different versions of ogr2osm, no matter which one you use - I prefer pnorman's, it's the most up-to-date. No matter what, make sure the translation files are compatible with the version of ogr2osm that you're using (for the sake of simplicity, the ones that I've linked to should be compatible with the version of ogr2osm). See here as examples for translation files that are compatible with pnorman's ogr2osm.
Ensure the translation file is complete with of all the information that you want in your shapefile. The translation file will convert your Types and attributes of the shapefile into what OSM calls Tags, which consist of Keys and Values.
1a. run ogr2osm.
Open josm, download the conflation plugin
Your gov data is now a osm file. Open josm, File > open
Your data is there as a layer.
If you already have the OSM data locally stored on your computer, open it in josm, it will also open as a new layer.
Merging these two sources of data together and resolving the duplicate data is known as conflation. Run the conflation plugin and resolve all of the conflicts.
If JOSM runs out of memory (e.g., when using large files), separate the types of attributes and complete this workflow multiple times, each with a different kind of data (e.g. boundaries and land uses; highways; buildings), and then finally merge the osm files together using osmium or another tool.
B. JOSM can also read shapefiles although SHP support isn't perfect and this method assumes the shapefile can be loaded entirely into memory...
- Start JOSM.
- Open the shapefile (e.g.,
filename.shp).
- Select all.
- In JOSM, Edit the attributes and properties that were imported from the SHP, and change them so each attribute corresponding an OSM tag.
- Save as OSM format.
- Continue from A4 and conflate
Import as OSM
Import the OpenStreetMap data into the system as follows:
- Change to the directory containing OpenStreetMap (OSM) files converted using JOSM.
- Execute the following commands in the database:
CREATE EXTENSION hstore;
osm2pgsql -j -W \
-d osm filename.osm
The -j option is key as it instructions osm2pgsql to import the tags into an hstore column, this preserving the underlying data structure and will import all tags into the database.
Create Mapnik Layer
To have the data appear on the map, add a layer and a style for that layer. This can be as simple as the following:
- Edit
mapnik-stylesheets/osm.xml.
- Insert the following XML code before the closing
</Map> tag...
...
<Layer name="prefix_zone" status="on" srs="&osm2pgsql_projection;">
<StyleName>zones</StyleName>
<Datasource>
<Parameter name="table">
(select way from prefix_line order by tags desc, z_order) as zones
</Parameter>
&datasource-settings;
</Datasource>
</Layer>
Create Mapnik Style
Continuing from the previous section:
- Find the last
</Style> tag (around line 3350).
- Insert the following XML code before the
&layer-shapefiles; directive:
...
<Style name="zones">
<Rule>
&maxscale_zoom1;
&minscale_zoom19;
<LineSymbolizer stroke="#0065BD" stroke-width="2.5" />
</Rule>
</Style>
Roadmatcher
roadmatcher is another tool that might be helpful
Best Answer
Probably you have seen the JCS Conflation Suite but in case you didn't, it works with Jump.