[Qgis-user] [OSM-talk] QGIS v MapInfo observations

[Nathan Woodrow]

While I am no longer a big fan of MapInfo to be fair it can now open
PostGIS databases.  UI have never really had a problem with it opening my
PostGIS database, although the interface is a bit old and crappy.

Georeferencing
>  - QGIS wins hands down, it is not easy but I manage, whereas MapInfo's I
> can rarely get started and crash it before I get anything done.


Been using  MapInfo since about version 6 and never really had any crashing
issues.  The main problem I have with Georeferencer in MapInfo is that it
sucks, interface wise, and how it handles the result raster.

Database retrieve
>  - QGIS is almost painless and what pain there is comes from MY not being
> able to set the DB up satisfactorily. MapInfo doesn't like PostGIS or mysql.
>

Once support was added never really had any issues.


>  Database store
> - I am unable to achieve in either. It SEEMS to me that something is
> missing in the instructions but I could be misreading them.
>

Not really sure what you mean by this.  Can you expand?


>  Foreign format import
> - QGIS plugin is painfully slow to import OSM and could benefit from more
> flexibility (if I could describe what I want, I expect improvement would
> come), MapInfo fails.
>

Agreed on both points.
MapInfo added support to open shp in version 9 I think however QGIS still
wins hands down with it's range of supported formats.


>  Foreign format export
> - MapInfo fails
>

Agree.


>  Editing layers
> - MapInfo is much easier for me to use so long as I remember to frequently
> save/pack tables, if I forget for too long parts of the table are lost when
> I do save/pack. The bulk of my editing is joining/splitting objects,
> converting objects between lines and polygons and adding information to the
> descriptive columns of objects. Those manipulations QGIS does handle are
> very slow on layers containing more than about 1000 objects and the layers
> I'm working on range from a couple of hundred objects up to 2 million
> (average about 200,000).


Agree mostly with the exception of entering data into columns, QGIS is much
better in this regard IMO.  Speed is one issue that I would like to see
sorted in QGIS, not a easy task and one step at a time.

- Nathan

On Thu, Mar 8, 2012 at 10:52 AM, mick <bareman at tpg.com.au> wrote:

> On Wed, 7 Mar 2012 12:29:37 +0000
> jonathanmoules at warwickshire.gov.uk wrote:
>
> > Much as I dislike MapInfo, that comparison is stacked against the
> > software. Not only is a very old version being used (He's using MapInfo
> > 7.8, apparently released in Sept 2004!!!! (
> > http://www.sgsi.com/Prod_Soft_MIPro_78.asp)), on top of which its being
> > run in WINE too, which will hardly improve the reliability.
>
> I admit I'm not giving MapInfo the best chance but I lack adequate
> hardware, the best Windows machine I have is an acer core 2 duo 2.4GHz with
> 2 GB RAM and a slow 160GB HDD running Vista. This once powerful beast idles
> at 30% memory use and 35% cpu use even after disabling everything I can
> keep it working without. Under this setup MapInfo performs worse than under
> wine with the exceptions that I can use the mouse to select line, region,
> text & symbol styles and the query 'wizard'.
>
> I did try MI8 trial release a few years ago on W2k and wine and was unable
> to install on either. If memory serves the problem was a late version if
> internet explorer was needed.
>
> >
> > I don't doubt QGIS would do well against a modern MapInfo deployment, but
> > lets not be disingenuous here, comparing a 7 year old product to a few
> > week old one isn't exactly going to convince naysayers.
> >
>
> The issues I observed in MapInfo have been present in all versions I have
> used since 4.2.
>
> mick
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20120308/4a2fb3b9/attachment.html>