I'm not sure that TVP is the one that people need, but if the
1:24,000 scale SDTS DLG files at the EROS data center are that
format, then yes, that's it. The DEMs seem to be handled fine by
Northwood Geoscience's Vertical Mapper import function, so we
don't need that one right away.
Output to MID/MIF is the sanctioned transfer format. There are
one or two people online here who have learned how to read and
write MapInfo native format files, but they can contact you
privately if they think it's worthwhile. The official doco for
the MID/MIF format (supplied by MapInfo) is at
http://www.directionsmag.com/mapinfo-l/mif/Table_of_Contents.htm.
I can help you with anything not fully explained there (like the
Coordsys clause, and I can supply you with an ASCII tab-delimited
file of all MapInfo-supported projections.)
Let's talk about the data model. Knowing little of SDTS, but a
lot about DLG, I know for example, that some lines that represent
roads can have multiple names or highway numbers. Canyon Blvd
here in Boulder is called "Canyon Blvd" and "St Hwy 119" and "St
Hwy 7" (there's only one canyon for all these to squeeze through
heading up into the mountains.) So here we would have one line
for the road and at least 3 attributes for some sections. MapInfo
handles these as a "View" table. The StreetInfo product is set up
like this, but it's not officially documented. I did write this
up once upon a time, and you can get it (streets.zip) from
http://www.directionsmag.com/tools/Default.asp?a=file&id=169
There are also cases where a line can be part of a shoreline as
well as part of the lake's enclosing polygon boundary, and you
might want them both. Also in hydrology layers there are points
associated with stream sources and fork junctions. It would be
great to have the ability to export, points lines and polygons
into separate layers as needed, even if these features are
coincident and can be interpreted differently depending on what
type of graphic entity they are.
I (with some help from people here) could certainly supply a free
MapBasic and Mbx to load, combine and style MID/MIF entities into
MapInfo tables if that would simplify the SDTS MID/MIF output.
Even better if you could build this as a DLL, and then we could
link it to an MBX and produce native TAB files on the fly.
Just some thoughts...
- Bill Thoen
Frank Warmerdam wrote:
>
> Folks,
>
> In response to recent discussions about the need for SDTS to MIF (or TAB)
> translation, I have decided to write a free sdts2mif translator. I am not
> normally a Mapinfo user, and so have a limited knowledge of Mapinfo, mostly
> garnered in the past from work on mif and TAB translators. As such I am
> interested on feedback indicating how to write optimally useful files for
> use in Mapinfo. Bill Thoen has kindly offered to help me a bit in this
> regard.
>
> I have read back through a couple dozen SDTS messages in the Mapinfo-L
> archive, and this is what I understand:
>
> o Vertical Mapper (as of a very recent version) includes SDTS DEM import,
> so there isn't really much need for me to support DEMs. Based on this
> I will concentrate on SDTS TVP (Topological Vector Profile) import. If
> DEMs are an issue, I can easily provide an SDTS DEM to GeoTIFF translator.
>
> o MID/MIF is equally useable in Mapinfo as TAB/DAT files, so it is sufficient
> to write MID/MIF.
>
> o Mapinfo is primarily (only?) available for Windows so it is sufficient to
> produce Windows .exe files for a conversion utility. (Note other platforms
> can be supported if desired. I normally write platform agnostic text
> mode programs).
>
> One question I have relates to the SDTS attribute data model. SDTS vector
> features (lines, polygons, etc) can have links to zero or more attribute
> records. These records can be in one or more tables. What I have done in
> the past when writing an SDTS2Shape translator was scan the whole vector layer
> for attribute references, and then establish an attribute schema which is the
> merged form of all tables references from the layer. I will do the same for
> Mapinfo output.
>
> However, some vector features have links to more than one records in the same
> table. For instance, some elevation contour datasets have more than one
> elevation record associated with contours. This seems to occur when several
> contour have been collapsed into one in very dense areas. The result is that
> one feature should be able to have several ELEVATION values associated with it.
> For now I am going to just assign one of the elevation values at random, but
> does anyone have an opinion on a better way of handling this? Is it a major
> issue?
>
> Another question I have is about what sort of graphical elements I should
> be using in the MIF file. Is it important that this be configurable on the
> translator command line?
>
> Finally, a few weeks ago someone asked if the FME support for SDTS was
> read/write or not. FME only reads SDTS datasets at this time, but the
> results can be written to any supported writable format, including MIF and TAB.
> As usual, a variety of manipulation can be applied during translation. FME
> is a good value for anyone needing to do an assortment of data translation.
> It isn't my intention to displace FME purchases, and in fact Safe Software
> funded the development of my underlying OpenSource SDTS library.
>
> Best regards,
>
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turned up | Frank Warmerdam, [EMAIL PROTECTED]
> light and sound - activate the windows | http://members.home.com/warmerda
> and watch the world go round - Rush | Geospatial Programmer for Rent
> ----------------------------------------------------------------------
> To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
> "unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]