Mats Elstöm wrote:
<snip>
When discussing the MI wish list, one really should adress this to the
Project Grande team, to make sure that this new MapInfo incarnation gets
the stuff we need from the start.
As has been pointed out, the legacy structure of MI Pro 8.0 prohibits the
adding of some of the qualities a modern GIS should have.
</snip>
I can see Mats' point of looking forward, but I disagree on the point
that the old architecture is a major obstacle to implement improvements.
As is, there are currently many clumsy implementations that introduces
new problems when trying to solve other problems. The localized indexing
is a prime example. They could easily be improved. And even rotated
raster images ought to be possible to implement. I really can only see
problems on the point of enhanced data format support, as MIPro is too
tightly integrated with the TAB format. And off course it's lack of a
full-fledged COM interface, but that's a minor concern for most end-users.
The old architecture is still solid and could be improved on many
points. But it's probably more a question of priorities, as in "why
waste time on a product soon to be phased out?".
Best regards / Med venlig hilsen
Lars Nielsen
GisPro
Mats Elfström wrote:
Hi all MapInfo Friends on this list!
I first, lest I forget: Happy Holidays to you all friends around the
globe.
MapInfo-wise, not much has happened in the core product we all use, but
behind the curtains great tidings are afoot.
When discussing the MI wish list, one really should adress this to the
Project Grande team, to make sure that this new MapInfo incarnation gets
the stuff we need from the start.
As has been pointed out, the legacy structure of MI Pro 8.0 prohibits the
adding of some of the qualities a modern GIS should have.
Now is the time to clean the closet and put in new shelves and wiring.
From what I understand of the presentation of Project Grande, their
ambitions are hight. It remains to be seen how far they will reach at the
first attempt.
Peter from Denmark wrote: I will also recommend everyone to pass on
feature requests to your MapInfo reseller and ask them to pass them on to
MapInfo. This is really the best way to tell MapInfo what you require. Of
course this doesn't always mean that your wish can be fullfilled...
I can vouch for that. The localization of MapInfo to Swedish is so badly
done that parts of it are laughing stock. I think it's done by someone
knowing neither GIS nor Swedish. I have argued this for years, both to the
swedish represesentative, and MI staff in Troy but to no avail. Just as an
example of their neglect: There is a typo in the main menus which hasn't
been corrected since version 5!
It's a pity that language barriers prohibits me from sharing with you the
funniest translation errors but there would be friday funnies for a year.
I would in fact go so far as to recommend MI Corp not to not bother making
a swedish version of MI 9 (or whatever P Grande will be called) if they
don't have the means to pay for a proper localization, done by people who
knows GIS, mapping, cartography and geodesy, knows swedish of course
fluently and also with the ability to write a comprehensible technical
manuscript.
Hälsning / Best regards Mats.E
________________________
FB Engineering AB
Södra Förstadsgatan 26
211 43 Malmö
Tel: 040-660 25 50
Mobil: 0705-27 60 27
Fax: 040-660 25 99
[EMAIL PROTECTED]
www.fbe.se
Peter Horsbøll Møller <[EMAIL PROTECTED]>
Sänt av: [EMAIL PROTECTED]
2005-12-23 08:37
Till
"Robert Crossley" <[EMAIL PROTECTED]>,
<[email protected]>
Kopia
Ärende
RE: [MI-L] Fixes and New MapInfo Features
Robert,
I agree. I also see this as the best way to store data, combining the
geographical part directly to the alfanumerical part - and this is actual
what MapInfo has been doing for many years.
But I can also see needs for more advanced topology features in MapInfo
eventhough there already is a lot that can be done, you just need to write
the application yourself.
By the way, it is possible to select all blue polygons using SQL: Select *
From MYTABLE Where Val(Str$(StyleAttr(ObjectInfo(OBJ, 3))) = RGB(0,0,255)
I will also recommend everyone to pass on feature requests to your MapInfo
reseller and ask them to pass them on to MapInfo. This is really the best
way to tell MapInfo what you require. Of course this doesn't always mean
that your wish can be fullfilled, but the more people wishing for a thing
the bigger the chance ;-)
And finally I would like to wish you all a merry Christmas and a happy New
Year
Peter Horsbøll Møller
GIS Developer, MTM
Geographical Information & IT
COWI A/S
Odensevej 95
DK-5260 Odense S.
Denmark
Tel +45 6311 4900
Direct +45 6311 4908
Mob +45 5156 1045
Fax +45 6311 4949
E-mail [EMAIL PROTECTED]
http://www.cowi.dk/gis
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Crossley
Sent: Friday, December 23, 2005 2:58 AM
To: [email protected]
Subject: RE: [MI-L] Fixes and New MapInfo Features
Bill,
I sort of disagree here. It would be nice if there was a hierarchy of
points, arcs and polygons and all of those modelling niceties were there,
but these were designed back when computers had less grunt than my
calculator. Is it a big advantage now?
Now, most of those sorts of calculations can be done by the software on
the fly, generally in less time than in the old days.
Arc's topology make it a good data capture tool, especially if you want to
avoid getting slivers etc between polygons - but if you want to follow the
same procedures, then surely there are some other good clean and build
tools.
I think that a far more important design feature is the intimate
connection between the spatial object and the data about it. After all,
arguably the most widely accepted spatial model is Oracle Spatial, and to
my knowledge, it stores the spatial object as part of the data, and lets
the software worry about topology.
I'm sure that this connection to the data makes the whole integrated
spatial and data query tighter.
R
-------------------------------------------
Robert Crossley
Agtrix P/L Australia
Far Southern Queensland Office:
9 Short Street
PO Box 63
New Brighton 2483
P: 61 2 6680 1309
F: 61 2 6680 5214
E: [EMAIL PROTECTED]
W: www.agtrix.com
Brisbane Office:
109 Milsom St
Cooparoo 4151
Queensland
P: 61 7 3843 3363
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Thoen
Sent: 23 December 2005 10:16
To: MapInfo List
Subject: Re: [MI-L] Fixes and New MapInfo Features
Søren Breddam wrote:
This shouldn't be hard to implement.. Topology is obviously more
difficult. If the topology issue was implemented, we could sell our
license to
Microstation ;-) And do even more interesting queries.
Well, in the beginning, MapInfo decided to use a simple model that
didn't need the rigorous set up that topology requires. When MI came
out, it was trivial to make a map -- you just drew what you wanted and
presto! You had a map. From the very beginning they were after the
business market, not the science people. In fact MapInfo's first product
was more like a pin-map tool to locate customers, franchises, etc. i.e.
strictly business. It's also why they've resisted being called a GIS,
opting instead for "desktop mapping." Business people don't know GIS,
and don't wan to know GIS, but they're bang alongside things that are as
accessible as a "desktop." MapInfo basically made a tool that could
associate data with drawings, which is actually a fairly powerful concept.
The alternative was Acr/INFO. To use that, you needed to understand GIS
at the techno-weenie level and build your map objects by first
establishing the nodes, then snap the arcs to those (assigning to and
from nodes) and then build polygons by assigning ids to the left and
right sides of the arcs. To do all this properly generaly took some
time, but in the end, you were assured that operations like dissolving
smaller areas into larger ones, or finding adjacent polygons or
traversing a network all became pretty straight-forward when you could
use arc-node topological math.
Personally, I prefer ESRI's model because I like the internal
consistency that topology adds. I also like their idea of associating
style information with data attributes rather than making it part of the
map data. That makes it easy to select information from the data with
SQL whereas in MapInfo, if you want all the blue objects for example,
you can't use SQL. But I must admit, there are times when MapInfo's
model is just so much simpler to implement and sometimes a map *is* just
a drawing with some data attached and you don't need to do anything with
topology.
My point is that I don't think MapInfo needs to be more "GISey" as much
as they should pay attention to what their core market and focus is (or
was.) It was business information analysis and presentation of spatial
data. That means not only do they need good analysis tools (and data)
but they really need to sex up their graphics presentation capability.
They aren't aimed at doing modelling or network analysis so they don't
*need* topology. But they do need better graphic tools so that the
software's output can blow the collective socks off an audience.
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
