Hi:

I have been playing around with the mitab stuff.

At present I am trying to get mitab_capi.h converted to MapBasic
so I can call mitab.dll from within an MB program.

(don't ask me why--MI has a rich, complete ObjectInfo(), i am just
thinking of porting conversion code from VB / Access whatever with a
minimum of code changes)

Anyway, this has me stumped!

the header declares mitab_feature like this I think---

typedef void * mitab_handle;
typedef void * mitab_feature;

--is there any equivalent in MapBasic? When I try to Dim and pass
around an Object variable it balks and won't even compile.

(The mitab_handle seems to work fine as an Integer)

Thanks!

Daniel Morissette wrote:
> For sure, if it is implemented inside MITAB then the auxilary file
> should be created only when you ask for it explicitly and it should not
> fail if the directory where the MIF file resides is read-only.
>
> One thing you could do is add a "bCreateAuxFile" flag to the
> GetFeatureCountByType() function with a default value of FALSE.  So in
> your case you can call with bForce=TRUE, bCreateAuxFile=TRUE and you get
> your auxilary file for MIF datasets, but you don't create an annoying
> side effect for those who don't need the file.
>
> Also, when a new .MIF dataset is created then the auxilary file should
> be deleted if there is already one with the same name as the new MIF
> file otherwise your GetFeatureCountByType() could sometimes return
> inaccurate results (coming from an older dataset).

Daniel,

For now I have chickened out of creating the auxilary file within mitab;
however, I have made the following changes.

  o TABFile will now set the geometry type on the OGRFeatureDefn if
    the features are all points, lines or regions (text counts as points for
    these purposes).

  o The MIFFile::PreParseFile() method will now collect detailed feature counts
    by type (points, lines, regions and text).

  o MIFFile::GetFeatureCountByType() will now actually utilize the results of
    a preparse pass if available, and if the application forces the count to
    be computed it will preparse the file to do so.

I also made a minor change to ogrinfo.cpp which requires an updated
ogr_geometry.h, and ogrgeometry.cpp (checked into ../ogr).

The above changes are checked into your CVS directory, and I am updating the
gdal/ogr/ogrsf_frmts/mitab directory based on your current source.  Let me know
if my actions screw anything up.  They _seem_ safe.  :-)

I haven't firmly decided whether to put the management of the .aux file within
mitab, or above it.  I would put it in mitab, except that my client may prefer
me to put all the auxilary information in one file for all datasets.  This
would be done in a pretty application specific way and so wouldn't belong in
MITAB.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerda@...
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent

Hi,

> Also, when a new .MIF dataset is created then the auxilary file should
> be deleted if there is already one with the same name as the new MIF
> file otherwise your GetFeatureCountByType() could sometimes return
> inaccurate results (coming from an older dataset).

I think the best thing to fixe that problem is by using the modify or creation
time,
If the user generate new MIF file from MapInfo, th count could be wrong.


regards,
stephane

Hi,

> > Does
> > this result in a full scan of the file for mif files?  I presume if I call
it
> > with bForce=FALSE, it will succeed for TAB, and fail for MIF ... is that
right?
> >
>
> For MIF files I will let Stephane confirm it, but I would expect that
> what you just wrote is true.

Yes, the answer is true,

  if bForce == FALSE
     return -1;
otherwise a full scan is performed


bye,
stephane

Frank Warmerdam wrote:
>
> Folks,
>
> A client of mine (GG) uses MITAB as the basis of their TAB and MIF readers.
> On opening a file it is desirable to be able to indicate to the user what
> sorts of features the file has, boiled down to points, lines, areas and
> text from the full mapinfo set of types.  However, I want to avoid doing
> a full scan of the data if possible to avoid slow "open" times.
>
> I see there is a GetFeatureCountByType() method on the IMapInfoFile derived
> classes, which would appear to do what I want:
>
>     virtual int GetFeatureCountByType(int &numPoints, int &numLines,
>                                       int &numRegions, int &numTexts,
>                                       GBool bForce = TRUE ) = 0;
>
> Does this just operate based on header for tab files (ie. it's fast)?

Hi Frank,

Yes, for TAB files the information comes from the header so it is fast.

> Does
> this result in a full scan of the file for mif files?  I presume if I call it
> with bForce=FALSE, it will succeed for TAB, and fail for MIF ... is that
right?
>

For MIF files I will let Stephane confirm it, but I would expect that
what you just wrote is true.

> Assuming the above is true, I was considering writing out an auxilary file for
> MIF datasets that would hold the count information when I force the scan the
> first time, and thereafter I could just get the counts from this auxilary file
> quickly.  If I do this, I could do it at a higher level ... in my own code, or
> I could incorporate this support right into the
MIFFile::GetFeatureCountByType()
> within MITAB.
>
> Any thoughts on whether this is advisable, and if so whether I should
implement
> this within MITAB or outside?
>

For sure, if it is implemented inside MITAB then the auxilary file
should be created only when you ask for it explicitly and it should not
fail if the directory where the MIF file resides is read-only.

One thing you could do is add a "bCreateAuxFile" flag to the
GetFeatureCountByType() function with a default value of FALSE.  So in
your case you can call with bForce=TRUE, bCreateAuxFile=TRUE and you get
your auxilary file for MIF datasets, but you don't create an annoying
side effect for those who don't need the file.

Also, when a new .MIF dataset is created then the auxilary file should
be deleted if there is already one with the same name as the new MIF
file otherwise your GetFeatureCountByType() could sometimes return
inaccurate results (coming from an older dataset).

Later,
--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.

Folks,

A client of mine (GG) uses MITAB as the basis of their TAB and MIF readers.
On opening a file it is desirable to be able to indicate to the user what
sorts of features the file has, boiled down to points, lines, areas and
text from the full mapinfo set of types.  However, I want to avoid doing
a full scan of the data if possible to avoid slow "open" times.

I see there is a GetFeatureCountByType() method on the IMapInfoFile derived
classes, which would appear to do what I want:

     virtual int GetFeatureCountByType(int &numPoints, int &numLines,
                                       int &numRegions, int &numTexts,
                                       GBool bForce = TRUE ) = 0;

Does this just operate based on header for tab files (ie. it's fast)?  Does
this result in a full scan of the file for mif files?  I presume if I call it
with bForce=FALSE, it will succeed for TAB, and fail for MIF ... is that right?

Assuming the above is true, I was considering writing out an auxilary file for
MIF datasets that would hold the count information when I force the scan the
first time, and thereafter I could just get the counts from this auxilary file
quickly.  If I do this, I could do it at a higher level ... in my own code, or
I could incorporate this support right into the MIFFile::GetFeatureCountByType()
within MITAB.

Any thoughts on whether this is advisable, and if so whether I should implement
this within MITAB or outside?

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerda@...
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent

----- Original Message -----

From: Daniel Morissette

To: mitab@egroups.com

Cc: landdan@...

Sent: Tuesday, May 23, 2000 11:16 PM

Subject: Re: [mitab] Geographic index.

> landdan wrote:
>
> MITAB group:
>
> Is anyone else seeing an indexing issues when importing from mid/mif.
> I have an application that selectively exports TIGER layers into
> MapInfo TAB files indirectly through MID/MIF.
>
> The problem is that some geographic entities are always selected
> within MapInfo when doing item selections.  For example, if you use
> the info tool and click outside of the county where there aren't any
> entities, you will receive information on entities within the county?
>

Hi Dan,

I just had a look at that problem using the sample files that you sent
me a couple of weeks ago, and it seems like the problem would be related
to the bounds used for each file by mif2tab.  After I forced the bounds
in the coordsys line of the 2 input files to be (-180,-90) (180,90) then
the problem went away.

Since coordinates are stored as integer values internally (with a
scaling factor and X,Y translation) in the .MAP file, the bounds of the
dataset have to be defined at the time the file is created.  MapInfo
uses some default bounds for each projection when it creates a new .tab
dataset, but the mif2tab program does not (yet) have that capability, so
it has to scan the source MIF file and use the MBR of the data in the
MIF file to define the bounds of the destination file.

As a result of that, unless you set them explicitly, the bounds of .tab
datasets created by mif2tab vary between files even if they are in the
same projection.  And it appears that displaying and querying at the
same time multiple layers with different bounds would confuse MapInfo's
spatial query function.

For now you can workaround the problem by explicitly setting bounds in
the source .MIF file, but a longer term fix would be to modify MITAB to
use the same default bounds as MapInfo when it creates a new .TAB
dataset.  This would also solve another problem that has been raised in
the past with respect to the precision of the coordinate values that
differs between files produced by MapInfo and files produced by MITAB.

It would be great if solving this was as simple as taking the extents of
the world in lat/lon and converting those coordinates to the destination
file's projection, but this would not be very optimal for coordinates
precision, in addition to the fact that some projection won't return
valid results for such huge coordinate values.

In brief, there is some experimentation work to be done to solve this
bounds problem... has anyone done anything on that front, or have any
idea of the way MapInfo defines its default bounds?

Later,
--
------------------------------------------------------------
Daniel Morissette                       danmo@...
              http://pages.infinit.net/danmo/
------------------------------------------------------------
  Don't put for tomorrow what you can do today, because if
      you enjoy it today you can do it again tomorrow.

---

---

To unsubscribe from this group, send an email to:
mitab-unsubscribe@egroups.com

> landdan wrote:
>
> MITAB group:
>
> Is anyone else seeing an indexing issues when importing from mid/mif.
> I have an application that selectively exports TIGER layers into
> MapInfo TAB files indirectly through MID/MIF.
>
> The problem is that some geographic entities are always selected
> within MapInfo when doing item selections.  For example, if you use
> the info tool and click outside of the county where there aren't any
> entities, you will receive information on entities within the county?
>

Hi Dan,

I just had a look at that problem using the sample files that you sent
me a couple of weeks ago, and it seems like the problem would be related
to the bounds used for each file by mif2tab.  After I forced the bounds
in the coordsys line of the 2 input files to be (-180,-90) (180,90) then
the problem went away.

Since coordinates are stored as integer values internally (with a
scaling factor and X,Y translation) in the .MAP file, the bounds of the
dataset have to be defined at the time the file is created.  MapInfo
uses some default bounds for each projection when it creates a new .tab
dataset, but the mif2tab program does not (yet) have that capability, so
it has to scan the source MIF file and use the MBR of the data in the
MIF file to define the bounds of the destination file.

As a result of that, unless you set them explicitly, the bounds of .tab
datasets created by mif2tab vary between files even if they are in the
same projection.  And it appears that displaying and querying at the
same time multiple layers with different bounds would confuse MapInfo's
spatial query function.

For now you can workaround the problem by explicitly setting bounds in
the source .MIF file, but a longer term fix would be to modify MITAB to
use the same default bounds as MapInfo when it creates a new .TAB
dataset.  This would also solve another problem that has been raised in
the past with respect to the precision of the coordinate values that
differs between files produced by MapInfo and files produced by MITAB.

It would be great if solving this was as simple as taking the extents of
the world in lat/lon and converting those coordinates to the destination
file's projection, but this would not be very optimal for coordinates
precision, in addition to the fact that some projection won't return
valid results for such huge coordinate values.

In brief, there is some experimentation work to be done to solve this
bounds problem... has anyone done anything on that front, or have any
idea of the way MapInfo defines its default bounds?

Later,
--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.

Hi,
I'm working on a project that needs to aggregate some informations
from various tables ( tab files )...

We're using tab2mif to convert our mapinfo tab files into mif files
so that we can concatenate the geographical informations..

The point is that when I use the mif2tab process, the projection
information is not the same I had at the beginning, eg. we have a
Lambert II carto ( which I guess is the same as Lambert II conic ) in
the original tab file, and after the manipulation, I get a
Longitude/latitude projection....

any clue ?

We've tried some things like doing a tab2mif from the original tab
file, and afterward import the mif file into Mapinfo, and the
projection stays unchanged.

This is obviously in the mif2tab that something goes wrong.

I'd need some help very quick, if you don't mind.

Thanks in advance.
Fab.

Hi Robert,

You are not the first one to run into that... so I'll CC: the
explanation to the MITAB list.

Prior to MapInfo 5.0, the island/hole information in a region (nHoles in
your objects dump) appeared to be ignored and no matter which value you
put in nHoles, the regions would always be displayed properly.

However, users have started reporting that the same region objects are
not displayed properly when using MapInfo 5.0 and up...  I have already
fixed the MITAB library to write the proper nHoles values in the file
_IF_ you give it the region sections (OGRRings) properly organized in a
hierarchy of OGRMultiPolygons and OGRPolygons.

This means that if you're using the C++ interface to the MITAB lib from
an application that knows which part of a region is a hole and wich part
is an island, then you can produce files that will display properly in
MapInfo 5.0 and up.


Unfortunately this fix does not apply if you're translating from MIF to
TAB using the mif2tab program since the MIF format does not carry this
island/hole information.  The plan is that I would like to add a method
to the TABRegion class that would go through all the parts and organize
them properly... for that I will need to write some polygon-in-polygon
tests, etc...

So the fix is on the ToDo list, but until I have the time to go through
that one, users will have to be aware of that limitation of the mif2tab
program.

Of course, if someone has some code or knows of a good OpenSource lib
that does this kind of geometry analysis (and more), then I would be
interested in hearing about it...

Best Regards,
--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.

EdwardsRG@... wrote:
>
> Hello Daniel!
>
> In checking out MITAB against our software, we found that MITAB does not
> (always?) handle holes correctly. For example, the example "mif" (below)
> should result in:
>
> Section #1 having two holes (Sec #2 and Sec#3); Section #4 should having one
> hole (Sec #5); Sec #6  is a "freestanding" region in the hole defined by Sec
> #3; Sec#7 is a "freestanding" region defined in the Sec #5 hole.
>
> The correct result is shown in the "dump" of objects following the "mif." A
> dump of the (incorrect) MITAB result follows that.
>
> Also, I note that the number of decimal places for this Lat/Lon) example is
> set to three. Perhaps something like six (perhaps eight or nine) would be a
> more appropriate value?
>
>   Robert Edwards
>   The MapTools Company
>
> ------------------------------------
>
> Version 300
> Charset "WindowsLatin1"
> Delimiter ","
> CoordSys Earth Projection 1, 0
> Columns 1
>   id Char(10)
> Data
>
> Region  7
>   5
> 0 1
> 1 1
> 1 0
> 0 0
> 0 1
>   5
> 0.93051 0.1704
> 0.93051 0.77579
> 0.822882 0.77579
> 0.822882 0.1704
> 0.93051 0.1704
>   5
> 0.74888 0.264574
> 0.74888 0.686099
> 0.273544 0.686099
> 0.273544 0.264574
> 0.74888 0.264574
>   5
> 0.608138 0.362299
> 0.497758 0.362299
> 0.497758 0.553222
> 0.608138 0.553222
> 0.608138 0.362299
>   5
> 0.582963 0.414798
> 0.582963 0.508968
> 0.522422 0.508968
> 0.522422 0.414798
> 0.582963 0.414798
>   5
> 0.567267 0.44843
> 0.544844 0.44843
> 0.544844 0.473094
> 0.567267 0.473094
> 0.567267 0.44843
>   5
> 0.470851 0.553222
> 0.470851 0.362299
> 0.415518 0.362299
> 0.415518 0.553222
> 0.470851 0.553222
>     Pen (1,2,0)
>     Brush (2,16777215,16777215)
>     Center 0 0
>
> ------------------------------------
>
> Importing: D:\dbGIS\InsideTest.tab  (MapInfo "tab")
>   id  C  0  10  0
> Importing 1 Database Records
> Import result: 0
>
> Overall XMin,YMin,XMax,YMax
> 1.000000  0.000000  0.000000  1.000000
>
> Brush #1 TimesUsed:1  2  16777215  16777215
>
> Object #1  (region)  ObjCode: 14/14  Attr: ""
> Region  7
>   Label X,Y: 0.000000  0.000000
>   Object MBR 0.000000  0.000000  1.000000  1.000000
> Section #1   nHoles: 2   nPoints: 5
>   Sec MBR 0.000000  0.000000  1.000000  1.000000
>    X,Y: 0.000000  1.000000
>    X,Y: 1.000000  1.000000
>    X,Y: 1.000000  0.000000
>    X,Y: 0.000000  0.000000
>    X,Y: 0.000000  1.000000
> Section #2   nHoles: 0   nPoints: 5
>   Sec MBR 0.822882  0.170400  0.930510  0.775790
>    X,Y: 0.930510  0.170400
>    X,Y: 0.930510  0.775790
>    X,Y: 0.822882  0.775790
>    X,Y: 0.822882  0.170400
>    X,Y: 0.930510  0.170400
> Section #3   nHoles: 0   nPoints: 5
>   Sec MBR 0.273544  0.264574  0.748880  0.686099
>    X,Y: 0.748880  0.264574
>    X,Y: 0.748880  0.686099
>    X,Y: 0.273544  0.686099
>    X,Y: 0.273544  0.264574
>    X,Y: 0.748880  0.264574
> Section #4   nHoles: 1   nPoints: 5
>   Sec MBR 0.497758  0.362299  0.608138  0.553222
>    X,Y: 0.608138  0.362299
>    X,Y: 0.497758  0.362299
>    X,Y: 0.497758  0.553222
>    X,Y: 0.608138  0.553222
>    X,Y: 0.608138  0.362299
> Section #5   nHoles: 0   nPoints: 5
>   Sec MBR 0.522422  0.414798  0.582963  0.508968
>    X,Y: 0.582963  0.414798
>    X,Y: 0.582963  0.508968
>    X,Y: 0.522422  0.508968
>    X,Y: 0.522422  0.414798
>    X,Y: 0.582963  0.414798
> Section #6   nHoles: 0   nPoints: 5
>   Sec MBR 0.544844  0.448430  0.567267  0.473094
>    X,Y: 0.567267  0.448430
>    X,Y: 0.544844  0.448430
>    X,Y: 0.544844  0.473094
>    X,Y: 0.567267  0.473094
>    X,Y: 0.567267  0.448430
> Section #7   nHoles: 0   nPoints: 5
>   Sec MBR 0.415518  0.362299  0.470851  0.553222
>    X,Y: 0.470851  0.553222
>    X,Y: 0.470851  0.362299
>    X,Y: 0.415518  0.362299
>    X,Y: 0.415518  0.553222
>    X,Y: 0.470851  0.553222
>  Pen,Brush Codes: 0  1
>     Pen (1,2,0)
>     Brush (2,16777215,16777215)
>
> ------------------------------------
>
> Importing: D:\dbGIS\InsideTest1.tab  (MITAB "tab")
>   id  C  0  10  0
> Importing 1 Database Records
> Import result: 0
>
> Overall XMin,YMin,XMax,YMax
> 0.000  0.000  1.000  1.000
>
> Pen #1 TimesUsed:1  1  2  0
> Brush #1 TimesUsed:1  2  16777215  16777215
>
> Object #1  (region)  ObjCode: 14/14  Attr: ""
> Region  7
>   Label X,Y: 0.500  0.500
>   Object MBR 0.000  0.000  1.000  1.000
> Section #1   nHoles: 0   nPoints: 5
>   Sec MBR 0.000  0.000  1.000  1.000
>    X,Y: 0.000  1.000
>    X,Y: 1.000  1.000
>    X,Y: 1.000  0.000
>    X,Y: 0.000  0.000
>    X,Y: 0.000  1.000
> Section #2   nHoles: 0   nPoints: 5
>   Sec MBR 0.823  0.170  0.931  0.776
>    X,Y: 0.931  0.170
>    X,Y: 0.931  0.776
>    X,Y: 0.823  0.776
>    X,Y: 0.823  0.170
>    X,Y: 0.931  0.170
> Section #3   nHoles: 0   nPoints: 5
>   Sec MBR 0.274  0.265  0.749  0.686
>    X,Y: 0.749  0.265
>    X,Y: 0.749  0.686
>    X,Y: 0.274  0.686
>    X,Y: 0.274  0.265
>    X,Y: 0.749  0.265
> Section #4   nHoles: 0   nPoints: 5
>   Sec MBR 0.498  0.362  0.608  0.553
>    X,Y: 0.608  0.362
>    X,Y: 0.498  0.362
>    X,Y: 0.498  0.553
>    X,Y: 0.608  0.553
>    X,Y: 0.608  0.362
> Section #5   nHoles: 0   nPoints: 5
>   Sec MBR 0.522  0.415  0.583  0.509
>    X,Y: 0.583  0.415
>    X,Y: 0.583  0.509
>    X,Y: 0.522  0.509
>    X,Y: 0.522  0.415
>    X,Y: 0.583  0.415
> Section #6   nHoles: 0   nPoints: 5
>   Sec MBR 0.545  0.448  0.567  0.473
>    X,Y: 0.567  0.448
>    X,Y: 0.545  0.448
>    X,Y: 0.545  0.473
>    X,Y: 0.567  0.473
>    X,Y: 0.567  0.448
> Section #7   nHoles: 0   nPoints: 5
>   Sec MBR 0.416  0.362  0.471  0.553
>    X,Y: 0.471  0.553
>    X,Y: 0.471  0.362
>    X,Y: 0.416  0.362
>    X,Y: 0.416  0.553
>    X,Y: 0.471  0.553
>  Pen,Brush Codes: 1  1
>     Pen (1,2,0)
>     Brush (2,16777215,16777215)

Stephen Cheesman wrote:
>
> I tried to open the latest mitab-1.0.1.zip file and WinZip returned the
> error message "Cannot open file: it does
> not appear to be  valid archive..."
>
> Could you re-create the zip file?
>

OOPPSss... the file was truncated... I uploaded a new copy.

Later,
--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.

Daniel,

For the SDTS2MI utility I am using the MITAB OGR bindings to write out mapinfo
files.  OGR uses a field width of zero to indicate variable length fields, but
this doesn't map well into mapinfo.  For now I have modified mitab_datfile.cpp
as follows, but I am not sure if this is the best solution.  Is this also
a problem for the .mif support?  Should the change be at a higher OGR plugin
level?

I added the following to TABDATFile::AddField(), near the beginning.

     /* remap variable length fields to be 255 long fields. */
     if( nWidth == 0 )
         nWidth = 255;

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerda@...
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent

Hi,

I have placed on the MITAB web site a new version of the library
that contains a simple C API built on top of the C++ library... it has
some limitations, but is much simpler to use than the C++ interface for
simple applications.

The C API documentation is available at:

   http://pages.infinit.net/danmo/e00/mitab-docs/mitab_capi.cpp.html

Also, this C API can be compiled as a DLL on Windows.  The DLL should
work well with C and C++ programs, as well as Delphi assuming that one
writes the proper Delphi definitions for the DLL interface.
Unfortunately I don't think it could be used from VB because of VB's
special way to deal with some data types such as strings.

Best Regards,
--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.

Daniel Morissette wrote:
>
> Does anyone know the complete list of valid characters in an ATTRIBUTE
> FIELD NAME in a TAB (or MIF) dataset?

Thanks to those who replied.  For the benefit of the other members of
the list who may have had the same question, here is the info I got:

Robert Edwards wrote:
---------------------

According to the MapInfo User's Guide (p. 240, v5.5)

New Table Command:
  Name:
Displays the field name in the name box. You can also enter new field
names here. Defaults are Field1, Field2, etc. A field name can contain
up to 31 alphanumeric characters. Use letters, numbers, and the
underscore. Do not use spaces; instead, use the underscore character (_)
to separate words in a field name. Use upper and lower case for
legibility, but MapInfo is not case-sensitive.

Phil Bolian wrote:
------------------

In addition to the "standard" upper/lower case alphabetic characters
(hex 41-5A, 61-7A), the digits, and the underscore (_), MapInfo also
accepts 62 "international" upper/lower case alphabetic characters from
the hex C0-FF range.  Hex D7 and F7 are not accepted because they don't
represent alphabetic characters.

Further, since MapInfo considers the naming of fields to be
case-INsensitive (field name "abc" refers to the same field as "ABC")
it's important to note that MI appears also to honor the upper-to-lower
relationship of characters in the C0-DF and E0-FF ranges,
respectively.  Thus, field name "clé" refers to the same field as "CLÉ"
(but, of course, not to the same field as "CLE" without accent aigu).

This additional range of characters includes all French vowels with
accents (aigus / circonflexes / graves), plus vowels with tréma, plus Ç
(upper and lower case).  There is no character in this range for the OE
ligature.  (The range does include other characters for western European
languages.)

Marco Alfaro wrote:
>
> My native language is the spanish.
> Mif2tab is good tool for me, but I need the file .ind (index of .dat).
> Do you can help me.
> Thanks.

Hola Marco,

The program mif2tab.exe currently ignores the indexed fields and won't
create the .ind file for you... I will have to fix that in a future
release of the MITAB package.

However, the tab2tab program does take the indexed field info into
account.  The name of the tab2tab program is a bit misleading since it
can also take MIF files as input (it automatically detects the format of
the source file).

So, to get the .ind file, you need to add the "index n1, n2, ..." line
in the source MIF file's header (see MIF specs), and then use
tab2tab.exe just the way you would use mif2tab.exe.

Also, I just added a precompiled version of the tab2tab.exe program to
the mitab-1.0-win32.zip archive on the lib's web site in case you do not
want to compile it yourself:
	 http://pages.infinit.net/danmo/e00/mitab-1.0-win32.zip

Regards,
--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.

Hi,

Does anyone know the complete list of valid characters in an ATTRIBUTE
FIELD NAME in a TAB (or MIF) dataset?  I know that some characters such
as '-' and spaces will cause problems but on the other hand rejecting
everything that is not an alphanumeric characters is not an acceptable
solution since it has been reported by users that some extended
characters (e.g. accentuated chars in French) that are currently
rejected by MITAB should be considered valid...

If anyone has already done some tests on that front or could quote a
part of the MapInfo docs that give that information then that could be
very useful to improve the filtering of the field names in MITAB.

Thanks,
--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.

Folks,

In followup to the problem I brought up a few weeks ago with mitab on 64
bit platforms, we have established that things work fine but care must
be taken with cpl_port.h, and cpl_config.h to ensure correct types are
used.  We used a hacked version and had to generalize it again.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turned up | Frank Warmerdam, warmerda@...
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent

David Takahashi wrote:
>
> 2) The second problem I have been working involves generating a mitab file
> with many custom points.  I am generating a 'merged' mitab file from 3000
> individual files.  When I hit 170716 points, the custom points will not
> display in the viewer.  If I continue to add more points (no count), the
> viewer will crash when bringing up display properties.  If I continue to add
> more points (say >300000) the viewer will crash when loading the file.  I
> have successfully read the file using mitab on the input side, and output
> using mfal thus proving the mitab read is not failing, and suggesting that
> something is wrong on the mitab output side.  The files in question have 18
> fields, 154 bytes wide, but the problem occurs when only two fields are
> generated in the output.  Any suggestions as to strategies for determining
> what's happening, or any gut hunches about whether its in the writing
> geometries or writing data??????

David,

The problem you ran into here is related to the way the spatial index is
built by MITAB inside the .MAP file.  I have to admit that the current
implementation does a very bad job with the spatial index... it all
worked well until users (like you and several others) started generating
files with over 100,000 objects which resulted in an overflow of the
index depth.  The exact number of objects required to produce the
overflow depends on the types of objects in your file.

This is becoming a very serious issue and I am planning to fix it
sometimes in the next few weeks by implementing a properly balanced
spatial index, etc... I hope to have a new version with that fixed
around the end of April.

Until then, I would like to warn all users that generating files with
over 100,000 objects with MITAB is dangerous and could result in crashes
when those files are opened in a viewer app.

Later,
--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.

The following is a message I posted shortly ago to the MapInfo-L
forum:

As an aid to those exploring the MapInfo "tab/dat/id/map"  and
"mid/map" definitions, I have updated the "map" specifications I
uploaded to our web site a few weeks ago. The URL for that
information is
   http://members.aol.com/MapToolsCompany/tabdef.txt

Also, I created a little Windows program (using Delphi) that will
dump out the "map" header and the spatial objects for a set of
MapInfo "tab/dat/id/map" files, and it will dump the "map" file
definition corresponding to a "mid/map" pair. The URL for that little
"exploring" program is
   ftp://members.aol.com/MapToolsCompany/dbgis.zip

The program is intended as a aid to learning about how minimum
bounding rectangles are handled, viewing the internal definitions of
symbol and font styles, etc. Be sure to read the "Notes" when you run
the program.

   Robert Edwards
   The MapTools Company
   http://members.aol.com/MapTools/

Hi

I've just been looking at the MapInfo-L where there was a question
about MapInfo linestyles.

MapInfo line drawing is pixel based. The Windows API only has 4 or 5
primitives for raster line style so my question is does anybody know
how mapinfo converts a raster line style into a line that can be
drawn at any angle and yet keeps the ends nice and round - is it
perhaps a BITBLT type operation?

I know Windows NT has some enhanced features for raster operations
but of course MapInfo runs on Windows 95/98.

The membership of the list seems to be expanding quickly !

Regards

Bob

Hi Stephane


Wow ....................!

I always thought that the DWG format was proprietary and copyright
protected by Autodesk.

I've thought for some time that a strong link between AutoCAD and
MapInfo would be very useful for users. It looks like this is a
possibilty now.

Thanks very much for you help.


Regards


Bob



In message <38EBCBC9.CCF59DED@...>, stephane villeneuve
<stephane.v@...> writes
>Hi,
>
>You could find information about DWG version 13 and 14
>http://www.opendwg.org
>
>I hope this will help you.
>
>
>regards,
>stephane
>
>
>bob@... wrote:
>
>> I was interested to read about the work you are doing in reading
>> MapInfo internals. Do you know if anyone has done similar work with
>> the AutoCAD Release 14 format and if so any links to useful sights?
>>
>> Regards
>>
>> Bob Young
>>
>> ------------------------------------------------------------------------
>> Special Offer-Earn 300 Points from MyPoints.com for trying @Backup
>> Get automatic protection and access to your important computer files.
>> Install today:
>> http://click.egroups.com/1/2344/6/_/_/_/954975493/
>> ------------------------------------------------------------------------
>>
>> To unsubscribe from this group, send an email to:
>> mitab-unsubscribe@egroups.com
>

--
Bob Young

Tim Rogers wrote:
>
> Hello,
>   I was wondering if anyone had used this library for an opensource
> project, or knew of an opensource project which used it.  I am looking for
> some example code, since there is not much that comes with the library
> itself.
>

Hi Tim,

You are right, there are not much examples and the library is not very
simple to use.  This is mainly because it was built using the OGR
library's object model which is an implementation of the OGC Simple
Feature specification.  One of the things we wanted at the beginning was
to be able to access MIF and TAB files through an SF-COM interface
(which OGR has).

However, Frank Warmerdam has written a C wrapper API for MITAB. This C
interface may have some limitations, but it will be much simpler to use
for those who do not need to control everything.

It is not part of the archive that's on the web site yet, but I will try
to write complete documentation for it ASAP (hopefully over the next few
days) and will make it available then.

BTW, I am not aware of any user that have made their MITAB-based
application publicly available, but if anyone has something to offer
then I will be happy to make that available on the web site or to add
links to it.

Later,
--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.

Hello,
   I was wondering if anyone had used this library for an opensource
project, or knew of an opensource project which used it.  I am looking for
some example code, since there is not much that comes with the library
itself.

Tim Rogers
Software Engineer
Global Atmospherics, Inc

Hi,

You could find information about DWG version 13 and 14
http://www.opendwg.org

I hope this will help you.


regards,
stephane


bob@... wrote:

> I was interested to read about the work you are doing in reading
> MapInfo internals. Do you know if anyone has done similar work with
> the AutoCAD Release 14 format and if so any links to useful sights?
>
> Regards
>
> Bob Young
>
> ------------------------------------------------------------------------
> Special Offer-Earn 300 Points from MyPoints.com for trying @Backup
> Get automatic protection and access to your important computer files.
> Install today:
> http://click.egroups.com/1/2344/6/_/_/_/954975493/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> mitab-unsubscribe@egroups.com

I was interested to read about the work you are doing in reading
MapInfo internals. Do you know if anyone has done similar work with
the AutoCAD Release 14 format and if so any links to useful sights?

Regards


Bob Young

Folks,

Has anyone used MITAB on a 64-bit system?  Should it work on such systems?
I have a client running into problems, and so will look into this problem.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerda@...
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent

Hi Everyone,

This message is to test that the new MITAB mailing list is actually
working... and BTW let everyone know that a new version (version 1.0) of
the MITAB library is now available on the lib's web site at:

	 http://pages.infinit.net/danmo/e00/index-mitab.html

--
------------------------------------------------------------
  Daniel Morissette                       danmo@...
               http://pages.infinit.net/danmo/
------------------------------------------------------------
   Don't put for tomorrow what you can do today, because if
       you enjoy it today you can do it again tomorrow.