Mapinfo Tab files and QGIS

[Glen]

Gents

I have a program that makes color coded Sectors in mapinfo, but when i
open ANY tab file in QGIS all of my colors go away what is worst it
changes color each time i open it

Any ideas?

G

[Bo Victor Thomsen]

QGis doesn't use the colour information stored in tab-files. (It works like ArcGIS in this respect)

1. Make a project in QGis which contain your tab-file.
2. Double-click on your tab file name in the QGis layer panel.
3. Choose tab "Style" in the resulting dialogue.
4. Choose "Categorized" as style method and push the "Classify" button.
5. Edit the resulting colour scheme to your liking.
6. Save the style. Your sectors will now have the correct colour.
   
7. Save the project.
   

Viola !

Further questions might be better answered on the q-gis user list (http://osgeo-org.1560.n6.nabble.com/Quantum-GIS-User-f4125267.html)

Regards

Bo Victor Thomsen
Aestas GIS
Denmark

[Bo Victor Thomsen]

Sorry, point 4:

• Choose "Categorized" as style method and push the "Classify" button.

Should be:

• Choose "Categorized" as style method, choose a column for categorization in the "column" drop-down box and push the "Classify" button.

Regards

Bo Victor Thomsen
Aestas GIS
Denmark

[Nathan Woodrow]

Hey Glen,

Yeah QGIS can't read the style information. QGIS uses OGR and OGR does
return basic style information for tab files, QGIS just doesn't use
it. It's on my TODO list for QGIS, just no time currently.

However what you can do is use a little python program I wrote to do
this exact thing, more info here
https://github.com/NathanW2/MapInfo-to-QGIS-style-generator/wiki/Using-MapInfo-to-QGIS-style-generator.

It will extract the symbols out of the MapInfo file and translate it
into a QGIS style. Currently works for symbols and lines (only colour
and width).

If you still have MapInfo installed, which I guess you do, I would
recommend using the:

python mapinfoToQgis.py my.TAB out.qml -c {columnName} --UseMapInfo

command as it will handle the query needed to get the symbols out.

It's not 100% but I find it gets me 90% of the way when import tab
files into QGIS when I need to keep the style the same.

- Nathan
woostuff.wordpress.com

[Mats Elfström]

Hi!
This is strange. Is it a decision from the QGIS developer, or a shortcoming of the libraries that are used for tab files?

One great advantage of the MapInfo native tab format is its ability to store map styles with the data itself. Unlike for instance shape files. I think users that know this would expect that information to show in QGIS as well.
I will investigate further on the QGIS list.

Regards, Mats.E

--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en

--
______________________________________________
Mats Elfström, Väpplingvägen 21, SE-227 38 LUND, Sweden
tel: +46 46 145959 / mob: +46 70 595 39 35
alt e-mail: mats.e...@telia.com

[Mats Elfström]

Answering my own post.
Many point out the speed and goodwill present in this mailing list.
Well I can tell you that the Qgis mailing list is equally good.
Within minutes, I got several kind responses to the question why Qgis does not notice tab file styles.

The gist of it is that even if the OGR libraries can provide this information, Qgis would have to create a thematic style set in order to show it. No one has done the coding for this. You may know that Qgis is Open Source, and developed by enthusiasts at their own time and expense (mostly). So tab files are treated equally to shape files which by design have no style information at all.

Else, Bo Victors response above applies, that you must do the styling in Qgis yourself.
The good thing is that you can save the style and apply it to other tab files, as long as your coloring scheme is consistent.

HTH Mats.E

[Uffe Kousgaard]

I assume QGIS is using MITAB and it supports reading styles.

But most likely QGIS started with SHP files and they do it very differently.

Regards
Uffe

[Nathan Woodrow]

Well QGIS is using OGR which uses MITAB, which can get the style info.

Yeah when Gray first wrote the OGR driver in QGIS, the driver was only
used to read shapefiles although the underlying OGR lib could support
more formats, also OGR didn't support styles at that stage. It does
now and this feature could be added if it was needed enough, just have
to get someone to do it.

- Nathan

[Bill Thoen]

From a "pure" GIS point of view, some people see carrying embedded styles with a feature object as mixing into the record what should be an attribute. They base this opinion on relational database theory and data normalization. (a theme color and pattern could be changed for the same object, therefor theme is not a intrinsic element of a record, but an attribute with variable values.)

That's the way the Arc/Node topology model sees it, and Shapefiles are (loosely) based on that philosophy. So you may run into some pushback In getting OGR or Quantum GIS to provide support for this.

Of course, sometimes when you break rules that are based on pure philosophy you may find better practical solutions. The simpler tab file format that doesn't require all the baggage of a pure arc/node structure is lots easier to use, gets the job done quicker, runs faster and if you're careful, produces results indistinguishable from the arc/node version at display scale.

[robert crossley]

The inherent colour available in MapInfo is one of 2 non-standard OGR features that MapInfo have had since its inception and people like.  The other is the geographic text object.  It means nothing in terms of the world, except perhaps a concept of painting a label on the ground, but is very useful for cartography.  Imagine if AutoCad decided that you had to use text that changed its size depending on the zoom for all drawings.

 

All of this becomes very obvious when you have to store objects in a generic database like SQL Server and you either lose the fature or see how MapInfo has to work around its loss.

 

MapInfo use their map catalogue and a MI_STYLE field to store the default colour for each object, and then program MapInfo to be able to interpret this when it is generating its objects later.

 

Text on the other hand, is still lost.  I have been trying to replicate the concept used for styles (store all the necessary properties and an alternate object on a SQL DB and regenerate the object when opening the table), but there is at least one property that I cannot retrieve from a text object to enable me to do this?   BTW – where is the official wish list for features in MapInfo/ MapBasic that PBBI might listen to?

 

Another point in favour of the MapInfo format is the direct relationship between the object and its data.  The record has all the information it needs about itself, spatial and data.  While the arc/ node topology might be very useful for editing, it is a lot of baggage when trying to analyse your data.  Hence why Arc needed the shape file format when it started trying to compete with MapInfo on the desktop.  Oracle and all the other spatial databases since do the same.

 

R

--

[Richard Greenwood]

Glen,

Not sure if this would be helpful in your case as it involves several
steps, but MapServer, via OGR, does read MapInfo colors (but generally
not patters). So you could setup a MapServer that would correctly
render your MapInfo colors as a WMS (maybe WFS?), which in turn can be
used in QGIS. In the map file you would use

LAYER
. . .
CONNECTIONTYPE OGR
CONNECTION "/path/to/myfile.TAB"
STYLEITEM "auto"
. . .
END

the last item tells MapServer to read the MapInfo color associated
with the object.

Best regards,
Rich

--
Richard Greenwood
richard....@gmail.com
www.greenwoodmap.com

[Nathan Woodrow]

>The inherent colour available in MapInfo is one of 2 non-standard OGR
>features that MapInfo have had since its inception and people like.

While I can see how it can be seen as a good thing I have always found
it to be a right pain in the butt. I am of the view that the styling
of a feature should be stored away from the data (you can have it in
one file with the data, just not on a row by row basis). Style should
also be used to show a graphic representation of data, data from the
layer, not just style for the sake of style. Having the style stored
per row can lead to all worlds of hurt when you have to change the
style of a object when the data underneath changes, example:

- Manhole = round point
- Inspection Opention = square point

Now I click on a old record and change the data from Manhole to
Inspection Opening (because someone stuffed up when entering the data)
yet the symbol stays the same, now I have to stuff around changing the
symbol as well; or if I make a new object I have to keep changing the
symbol back and forth to enter new ones because MapInfo doesn't know
there is a link between Symbol and Data. This doesn't scale so
maintaining style consistency requires 3rd party tools; yes MapCAD can
help some of this pain, but really it's a workaround.

Of course there is always thematics, well there would be in they
weren't broken. Can't add more values, delete values, don't support
more then one object per thematic and no way to force the object
type. Lots of pain this way too.

I much prefer the "here is my data, generate unique symbols for that
data. When I change that data you update the map", if I change the
symbol half way though all my symbols are updated in the display. No
stuffing around changing the symbol too.

Of course there is some good things about storing the styles per row:

- speed, would be much faster to read the style there then look it up
in a different area and search for the value in the list;
- you can also make maps with data that doesn't match the style, but
how often do you do this? And even if you did do it it's not hard to
do this with the QGIS way of doing things, just make a column and put
the values the style refers too (good practice anyway IMO);
- portability, sure opening a tab file on one computer will look the
same as another computer because the style information is embedded,
but QGIS (I don't know if Arc has the same kind of thing) lets you
store a .xml style file with the same name as the file and it will
open that as the "default style".

>The
> other is the geographic text object.

This is one thing the Tab format does have and no other format does.
Can be a good thing, can be a bad thing, but for cartography yes it's
a good thing. I'm sure sure how Arc deals with this, I think they have
annotations, which QGIS kind of has but not very strong support.

- Nathan

On Feb 10, 5:20 am, "robert crossley" <rob...@wotzhere.com> wrote:
> The inherent colour available in MapInfo is one of 2 non-standard OGR
> features that MapInfo have had since its inception and people like.  The
> other is the geographic text object.  It means nothing in terms of the
> world, except perhaps a concept of painting a label on the ground, but is
> very useful for cartography.  Imagine if AutoCad decided that you had to use
> text that changed its size depending on the zoom for all drawings.
>
> All of this becomes very obvious when you have to store objects in a generic
> database like SQL Server and you either lose the fature or see how MapInfo
> has to work around its loss.
>
> MapInfo use their map catalogue and a MI_STYLE field to store the default
> colour for each object, and then program MapInfo to be able to interpret
> this when it is generating its objects later.
>
> Text on the other hand, is still lost.  I have been trying to replicate the
> concept used for styles (store all the necessary properties and an alternate
> object on a SQL DB and regenerate the object when opening the table), but
> there is at least one property that I cannot retrieve from a text object to

> enable me to do this?   BTW - where is the official wish list for features

[Bill Thoen]

I'm with you, Nathan. I prefer the the "pure" data model too where everything is normalized and linked properly and styling is one or more attributes in a table. That allows for lots of choices in flexibility. I have often imposed this environment over MapInfo and I get regions that are easier to edit, no "slivers" and all lines snapped to nodes. The data packs better and and being that it's a graph in the mathematical sense there's regular methods you can use to verify connectivity, etc., it's a useful data structure too. It's amazing the kinds of problems that graphs (networks) can solve cleanly.

But this model is also harder to set up and maintain without software tools and those aren't available to everybody. So I think it was a conscious design decision to make it really easy to make basic maps. Other features like records maintaining their own map features or carrying complete map feature objects per row are just plain simpler to use, even though they may be intrinsically flawed.

Bill Thoen
GISnet
http://gisnet.com
303-786-9961

On Feb 9, 2012, at 3:00 PM, Nathan Woodrow <madm...@gmail.com> wrote:

>> The inherent colour available in MapInfo is one of 2 non-standar OGR

[robert crossley]

Nathan your points are absolutely valid on both individual object styles
regarding both the data integrity and thematics being a limiting method of
overcoming display issues based on data because they are static.

I like the individual style option for speed, and many of my clients just
use a table for display, so when they option a table up, it should look like
a map without fiddling with thematics. I think you can set up default
thematics in the tab file or something, which would achieve that as well,
but then you would still have the issue with thematics when new categories
are changed and speed as well.

I am currently setting up a map display using MapServer for large data sets
of points, and may well create tables for display that have been
pre-rendered for colour, just to achieve the speed objectives. Perhaps not
absolutely correct, but practical. Those files are only ever used for web
display, and are generated programmatically based on the data in the
original tables (which have no individual styles).

I like having an option.

Re the text issue, I would really like to work with PBBI in coming up with a
solution on how we can store and retrieve text objects from a SQL database.
I can do it with non-rotated objects successfully now, but am screwed with
rotated objects. I am storing its geographic bounds in SQL, and storing
its properties in an associated table. Perhaps we could do something with
MI_STYLE for them, or use MI_TEXTSTYLE and MI_TEXTSTRING to define what we
want. Am happy to work with anyone on this issue, but have hit a brick wall
while I can't access an unrotated text height parameter that apparently is
available, but not exposed to Mapbasic. I have a corporate, multi-user,
distributed site, mapinfo application, that still relies of passing local
files around because I can't store text objects in SQL.

R

[Peter Horsbøll Møller]

>> BTW – where is the official wish list for features in MapInfo/ MapBasic that PBBI might listen to?

Try ideas.pb.com

Peter Horsbøll Møller
Pitney Bowes Software

--
Peter Horsbøll Møller
Pitney Bowes Software

[robert crossley]

Thanks.

 

Google took me to an old unofficial one.

 

R

[Glen]

Gents
thanks for the help and now understand why they do not work correctly
new question if i port my sector making program over to qgis
I can only create a python plugin? I can't call QGIS from VB.net?

any examples?

[Nathan Woodrow]

Glenm

That's correct. Currently QGIS only supports plugins written in
Python or C++. I have explored the .NET route for Qt objects but the
bindings for Qt->.NET aren't really active or stable and I was never
able to get them to work. A guy on the team was playing with the idea
of using Javascript as a supported plugin base but that hasn't gone
anywhere yet, only prototyped.

Technically you can call QGIS from .NET using marshalling via a
managed .NET C++ lib but this is not supported or even explored so you
aren't going to find much that way.

One thing that has always stopped me exploring the .NET route more is
that QGIS is cross platform, as is Python, where .NET isn't really
(yes I know there is Mono) and I don't really think splitting the eco
system up would be well received by the community.

- Nathan