Re: MI-L Line generalisation
Hi David Five possibilities I can think off. First one is are you packing the table after doing the thinning? A pack should make it smaller as it removes deleted records. When you thin record 1 it becomes say record 1211001 but record one stays there until the geometry block is again changed. More likely is that the projection of the original table has different bounds to the one that you save to. For example if you were thinning say Meridian or Oscar , and the original was unbounded. If you then save to bounded ( eg (0,0) (2000,2000) km ) then more geometry will be stored as 4 byte long ( rather than 2 byte short ) so the size of the file could go up. A third point is that because it is likely each segment of road begins and ends at a link, they might be quite short segments and therefore the percentage of nodes removed might be quite small. A fourth point is that the physical number of records will not change. Therefore the spatial index will be the same size, and if you did not pack could be bigger. The "save copy as" would effectively do a pack, so perhaps you are using tighter bounds? The fourth possibility is that the original tables were not created with MapInfo technology. For example the data provider might have used Safe Software. When creating the Map File there is a "redundancy" in the storage. This is actually beneficial as you can insert new records quickly into this redundant space. When you actually fill a partition it actually has to be split and at this time two new partitions that are only just over 50% full are created - hence on these two almost 50% redundancy. Your source data is expected to be read only and perhaps some other technology eg Safe has removed a lot of this redundancy. Good for read only , but not so good if you were inserting new records into the MAP file. Files created and packed by MapInfo typically have 25% redundancy. Regards Bob www.mapsbydesign.co..uk >All, > >There are some strange goings on inside my computer that I find hard to >understand...can anyone help. > >In the course of my daily grind I have found it necessary to generalise a >dataset of polylines that represents a road network. This particular dataset >is quite heavy and at the scale I am printing it the detail is not >important. So I am using the Object > Snap/Thin tool in MapInfo to thin down >the number of nodes in the network. > >That done my network is generalised, so I save the table, pack it, close it >and have a look at the file size in explorer > >...would you believe that despite removing detail from the MAP file by >generalising the network the *.map file is marginally bigger than the >original?! Can anyone explain this one for me, it seems a little backward? I >have tried this with several different networks of differing detail and >geographical spread with the same result. > >Also, in the process of this task I have noticed that using the 'Save copy >as' feature also creates a set of files where the *.map file is bigger than >the original...despite it being a COPY? > >If someone could shed some light on these weird occurrences, my Wednesday >afternoon would not have been in vain! > >Many thanks, Dave > > >This email and any attached files are confidential and copyright protected. >If you are not the addressee, any dissemination of this communication is >strictly prohibited. Unless otherwise expressly agreed in writing, nothing >stated in this communication shall be legally binding. -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 15978
Re: MI-L *.Map files
Hi Brian The MAP files contain the graphical data. It also contains style information for the objects and it contains an hierarchical spatial index - an RTREE index. Finally the header contains information from which the base unit, the bounding rectangle, and the projection can be derived. For completeness, the DAT file contains the data attribution, the optional IND file contains 1 or more indexes on the DAT file. The ID file contains a 4 byte pointer into the MAP file to link records in DAT to their graphical representation in the MAP file. The fact a 4 byte pointer is used (signed long) is the reason a MAP file is limited to 2 GB. Also pointers in the MAP file that point into the DAT file are also only 4 bytes limiting the maximum size of the DAT file. The final TAB file is an ASCII file that describes the TABLE. When describing the Native files format it lists all fields in full. This is a more complete description than the header on the DAT file ( The DAT file header takes the form of a DBF header and does not document integer, smallint and float as done by the TAB file ). The TAB file can also describe SQL selects, links to raster and links to XLS or DBF. It is therefore possible to create a SHP file from just the MAP file. Hope this is useful to you. Regards Bob www.mapsbydesign.co.uk >I have received ESRI GIS files from my client that I am having trouble >coverting >to MapInfo, I have some SHP files which I can import successfully, however >some >files appear only to be stored in the *.MAP file format. Is there any way I >can >access the data in these files? > >If I can access MAP files do they have object data or are they just purely >graphical data (i.e. polygons, lines, etc.)? > >TIA > >Brian > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 16034 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16038
Re: MI-L RE: Spam:MI-L Mobile and 3D line of sight etc.
Hi Roy Could you please explain this request a little further? Bob > >Any utilities available to extract grid values and assign to a point >table based on the point's coordinate location? > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 16294 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16304
Re: MI-L OPen Mapinfo files on GPS softwares
Maps4Site views MapInfo tables and supports GPS. The Lite version is 199 pounds. Details at www.maps4site.co.uk. Its designed to compliment Desktop MapInfo. Users can export captured data as MID/MIF or GML for import back into MapInfo. Bob MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes >Are there any GPS softwares (cheap in price) that >open MapInfo files. I have a route created in MapInfo >that I want to load onto a GPS application, so I can >follow a route. > >Thanks > > > > >__ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 16618 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16627
MI-L Danish Coordinate Systems & WGS84
Dear MI Users Can anyone please give me a pointer to formulae to convert WGS84 co- ordinates caught on GPS into System 34 Danish co-ordinate system. Also can anyone explain why MapInfo shows the true origin to be at Lat/Long 9,0 and a false origin of 50,0 and yet these do not actually fit Danish data in System 34. The only reference I have found so far is www.kms.dk but this does not list the formulae or the true parameters. Hope someone out there can help. Thanks Bob Young MapsByDesign.co.uk -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16643
MI-L German Coordinate Systems
Dear List I notice that MapInfo does not contain a section listing German Coordinate Systems. Could someone please let me know what projections are used by German MapInfo users. ED50 would seem to be one option except the y coordinates would be very large. Is the same projection used for the whole of the Country, and how about Austria - do they use the same? Most European countries seem to have their own section in the MAPINFOW.PRJ file. Why is Germany different? Thanks, Bob MapsByDesign.co.uk -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16788
Re: MI-L Precedence of overlaying points
Hi Alan You cannot control the draw order of a single layer. I would recommend you build a query that selects all records where date is 2000 or greater into a new query called say Pink. Then in layer control add Pink and make sure it appears above the layer with all records. Regards Bob www.mapsbydesign.co.uk In message <[EMAIL PROTECTED]>, Alan Hale <[EMAIL PROTECTED]> writes >I have a simple map with points colour-coded according to date class (pink for >2000 and later and gray for pre-2000). I want to ensure that where dots >overlap >when zooming out that the pink dots overlay the gray. Any suggestions please? > > > >Alan Hale >Ecolegydd Isblanhigion/Lower Plant Ecologist >Cyngor Cefn Gwlad Cymru/Countryside Council for Wales >Aberystwyth > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 16855 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16857
Re: MI-L Coordinate question
Hi Norm I am confident that your second question is accomplished by doing a "Save copy as" from the file menu. In the bottom right corner of the resultant dialog box you can set the projection of the new copied table to any MapInfo projection - in your case you would want to set WGS 84. On the first question, you are already working in an Earth Projection. This earth projection will have a datum, that is an ellipsoid with values for Major, Minor Radii etc. Therefore my guess is that the lat long is your position on this datum. The other possibility is that when MapInfo converts from one projection to another and thus from one datum to another it probably does this by use of one "master" datum. Thus I suspect to go from A to B MapInfo transforms A to master and then master to B. I would further suspect this "master" is WGS84. When you transform from one datum to another you need to allow for datum shifts and datum rotations. A use of some intermediate datum would certainly make this task easier. So for the first part my guess is that lat long is in your projections datum but might just be in the "master" datum. Regards Bob www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Norm Shea <[EMAIL PROTECTED]> writes >I have a question about switching between coordinate systems (and maybe this >is something I need to take a class on or something but here it is anyway). > >Our map is from Charleston County so is in US State Plane South Carolina >3900 (1983, feet). If you have the 'cursor location' selected in the bottom >left corner, it will show the readings in Northings and Eastings feet. If >you change the Coordinate Units under Map>Options to display degrees, you >get Lat/Lon readings. > >If you are trying to share this information, and give them Lat/Lon readings, >what coordinate system would you say the readings are in? Would you say >they are US State Plane South Carolina 3900 (1983, feet)? That somehow >doesn't seem like that would work. > >And how would you convert Lat/Lon readings in US State Plane South Carolina >3900 (1983, feet) to say, WGS84? Is there a conversion tool or a website >that you can do that? > >Thanks > >Norm Shea >Director, Lakes Management >Kiawah Island Community Association >20 Kestrel Court >Kiawah Island, SC 29455-5657 >843-768-2315 office >843-768-0298 fax >843-708-3608 mobile >[EMAIL PROTECTED] > >Confidentiality Notice: >This e-mail message, including any attachments, is for the sole use of the >intended recipient(s) and may contain confidential and/or legally privileged >information. If you are not the intended recipient, please contact the >sender by reply e-mail and destroy all copies of the original message. Any >unauthorized review, use, disclosure, or distribution is prohibited. > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 16858 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16868
Re: MI-L Coordinate question
Hi Norm I forgot to add - having saved your Easting, Northings file as WGS84 you can then export this as MID/MIF file to see coordinates listed as lat/long. Cheers Bob www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Norm Shea <[EMAIL PROTECTED]> writes >I have a question about switching between coordinate systems (and maybe this >is something I need to take a class on or something but here it is anyway). > >Our map is from Charleston County so is in US State Plane South Carolina >3900 (1983, feet). If you have the 'cursor location' selected in the bottom >left corner, it will show the readings in Northings and Eastings feet. If >you change the Coordinate Units under Map>Options to display degrees, you >get Lat/Lon readings. > >If you are trying to share this information, and give them Lat/Lon readings, >what coordinate system would you say the readings are in? Would you say >they are US State Plane South Carolina 3900 (1983, feet)? That somehow >doesn't seem like that would work. > >And how would you convert Lat/Lon readings in US State Plane South Carolina >3900 (1983, feet) to say, WGS84? Is there a conversion tool or a website >that you can do that? > >Thanks > >Norm Shea >Director, Lakes Management >Kiawah Island Community Association >20 Kestrel Court >Kiawah Island, SC 29455-5657 >843-768-2315 office >843-768-0298 fax >843-708-3608 mobile >[EMAIL PROTECTED] > >Confidentiality Notice: >This e-mail message, including any attachments, is for the sole use of the >intended recipient(s) and may contain confidential and/or legally privileged >information. If you are not the intended recipient, please contact the >sender by reply e-mail and destroy all copies of the original message. Any >unauthorized review, use, disclosure, or distribution is prohibited. > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 16858 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16869
Re: MI-L writing a special character into text file
Hi Christophe You can use the "Character Map" windows tool to report on the ascii values of your character set. On mine the degree symbol you want is 176 so in MapInfo this can be printed as chr$(176). If you open a MapBasic window and type in print chr$(176) you will see your character in the message window. With regarding to writing to a file if you open with dim lsString as string Open File for output as #1 lsString = "19.4" + chr$(176) write #1, lsString you will get your character in the file. Thus any character values will be written out ie from chr$(0) to chr$(255). Hopefully this is what you want to do - perhaps the character appearing in a report. If you want to read and write single bytes in a binary mode however ie Open File lsFile for binary access write as #1 I do not think MapBasic can do this. I would recommend writing C DLLs that you link to MapBasic for writing binary files. You can write short, long and double with MapBasic but MapInfo does not have a BYTE data type. If you use fixed length strings ie dim lsFixed as string * 1 then you are limited to printable characters chr$(32) to chr$(126). You can not read or write variable length strings with MapBasic in binary mode. Regards Bob www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Christophe Brabant <[EMAIL PROTECTED]> writes >Hi > >I would like to write this character : ° >into a text file, with Write statement for example. > >Don't work if I use litteraly : Write #2 , "°" >Don't know if i can use Chr$(), I don't find the right code number into >ASCII table. > >Christophe -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16870
Re: MI-L creating an Arc drawing tool
Hi Martin One option is to draw a polyline that consists of several small chords of the circle you desire. The chord wants to be small enough that the "flats" do not show at the largest scale required. Its a little inefficient on storage but works. Something like 30 chords will look smooth unless you need to zoom in a lot. I'd also suggest one data attribute to store the fact you regard it as an arc and another for its radius for report purposes. This is how Ordnance Survey store their arcs, and also how MapInfo and AutoCAD render their arcs for display purposes. Regards Bob www.MapsByDesign.co.uk In message , Martin Hodder <[EMAIL PROTECTED]> writes >Hi, > > > >I want to replicate the MI ARC Drawing tool. > > > >There does not appear to be a custom arc drawing mode. So I was going to use >the line drawing mode to get the start and end point lines and then use the >create ARC mapbasic statement. > > > >However this appears to create an ellipse rather than an arc. > > > >Has anyone manages to create an arc between two points? > > > >I could set the layer editable and use the standard drawing tool. But there >are things I want to check before the Arc is inserted into the table. > > > >Many thanks > > > >Martin > > > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 17412
Re: MI-L Old MapInfo version running new MapBasic scripts
Hi Jae Yes it is, provided your MapBasic code does not call "features" of the later version. There is a freeware utility that will "recompile" compiled code to an earlier version, if features of later versions have not been used. One of my colleagues uses this, but I will not see him until Friday. If nobody else responds with the name of the utility before Friday I will send you the details then. MapInfo compiled code is not true machine code, but rather a pseudo code with tokens for instructions, variables etc. So if you have a MapInfo 7.5 MBX that uses features that were all available in MapBaisc 4.5 this utility will recognise this fact and rewrite the header so that it appears to have been compiled with 4.5. Hope this helps. Regards Bob www.MapsByDesign.co.uk In message <[EMAIL PROTECTED] consulting.com>, Behrmann, Jae <[EMAIL PROTECTED]> writes > >Is it possible to run MapBasic version 8 scripts in an old version of MapInfo >(i.e. version 5.5)? > >Thanks, >Jae Behrmann > > > >*** >The information in this email is confidential and may be legally privileged. >Access to this email by anyone other than the intended addressee is >unauthorized. If you are not the intended recipient of this message, any >review, disclosure, copying, distribution, retention, or any action taken or >omitted to be taken in reliance on it is prohibited and may be unlawful. If >you >are not the intended recipient, please reply to or forward a copy of this >message to the sender and delete the message, any attachments, and any copies >thereof from your system. > >*** > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 17442 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 17445
MI-L Calling all C programmers - help with bug
Dear List
If any C programmers on the list can see a bug in this code I would be
most grateful!
The code has been cut from a much larger program. The code stays inside
the while loop as the line jCount++ does not get executed for some
reason.
I have extracted the code from an EXE and built in a DLL that can be
called from MapBasic or VB and each time it stays in loop. If the code
is changed slightly it works, but as is - will not.
Any one with any ideas??
Code as follows
#include
#include
long Example1()
{
long iFlag = 0;
long lnOranges = 0;
long lnApple[100];
long jCount = 0;
long lnThreshold = 0;
char lsString[100];
lnOranges = 2;
lnThreshold = 1;
for (iFlag = 0; iFlag < 2;iFlag++)
{
if (lnOranges> 1)
{
jCount = 0;
while (jCount < lnThreshold)
{
strcpy(lsString,"string");
lnApple[jCount] = 0;
jCount++;
}
}
else
{
lnThreshold = 1;
}
}
return 9;
}
--
bob young
-
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 18189
MI-L Problem C code follow up
Dear List
Thanks to everybody who responded to my query regarding C code.
Two members, Bill Thoen and Tony at English Nature suggested making all
longs explicit eg 0L and 2L etc. I tried this but it made no difference.
Two other members, Warren Vick and Kris Woodland, said that they tried
the code and it worked. Therefore they suggested perhaps I had some
string values that overwrite lsString[100] ie more than 100 characters.
However the code "as is" goes wrong with my Microsoft compiler ( Version
6.0 ). ( In the original version lsString is actually 200 bytes and is
never set longer than that ).
I enclose the code again, but this time I have the longs explicit and
also this time I have included the DLLExport etc for use with MapBasic.
( The version I enclosed earlier was for calls from VB - this one is for
calls from MapBasic ). I have enclosed some simple MapBasic code to call
the DLL.
I would be really keen to know the compiler settings, Warren and Kris
are using when they have the code running. I am using all the Microsoft
defaults. I have also now included some mapbasic code to test the
compiled DLL ( This assumes the compiled DLL is copied to the root of
Drive C ) for anyone else who might test the code. The solution must be
in these compiler settings !!??!!
The original code was much larger than this, and it was quite tricky to
narrow down the code to these twelve lines or so and maintain the
problem! Slight amendments allow the code to work, but I need the
original like it was and thus need this precise code to work as is.
Warren thought that perhaps there were other functions in the DLL
interfering, but the version here ( and the earlier version ) are the
complete DLL and it goes wrong every time in both VB ( as long ) and in
MapBasic as BYOUT(long) ie with DLLExport etc. The reason I only have
this routine in the DLL is that the original code was in a large EXE so
I have now isolated the problem to just twelve lines of code or so, in
an isolated DLL.
Its as if the compiler optimiser thinks the while statement does not
make use of jCount. If code is included to test the value of jCount the
code runs OK ( ie bug disappears) ! However the WHILE statement actually
tests jCount and it would appear it stays as 0 in code included. If the
else condition lnThreshold = 1L is removed the code runs OK and yet this
code should never get called as lnOranges is always > 1. If either
strcpy(lsString,"string"); OR lnApple[jCount] = 0; are commented out
again the code will run. The interaction of all the lines seems to cause
the bug.
Any help very very greatfully received!! I have sent the code to
Microsoft support. It would be great if the MapInfo community could
solve this first!
Regards
Bob
HERE IS THE C CODE (with explicit longs OL etc) and MapBasic calls
#include
#include
#define BYOUT(returntype) __declspec(dllexport) returntype __cdecl
BYOUT(long) Example1()
{
long iFlag = 0L;
long lnOranges = 0L;
long lnApple[100];
long jCount = 0L;
long lnThreshold = 0L;
char lsString[100];
lnOranges = 2L;
lnThreshold = 1L;
for (iFlag = 0L; iFlag < 2L;iFlag++)
{
if (lnOranges> 1L)
{
jCount = 0L;
while (jCount < lnThreshold)
{
strcpy(lsString,"string");
lnApple[jCount] = 0;
jCount++;
}
}
else
{
lnThreshold = 1L;
}
}
return 73;
}
HERE IS SIMPLE MAPBASIC CODE TO CALL THE DLL PROVIDED IT IS IN ROOT OF
DRIVE C
Declare Sub Main
Declare Sub CallBug
Declare Function Example1 lib "c:\bugA.dll" () as integer
Sub Main
Create Menu "Bob" as
"Bug" calling CallBug
Alter Menu Bar add "Bob"
End Sub
Sub CallBug
dim lnLong as integer
lnLong = Example1()
print "Returned " + lnLong
End Sub
END CODE
If line(s) are commented out ( eg lnApple[jCount] = 0 ) to allow code to
run the MapBasic program prints 73. However the code as is never returns
and from other debugging I am convinced the Microsoft compiler is not
incrementing jCount within the while loop with code as is. There seem to
be no string overruns, and no use of pointers - the normal cause of such
very frustrating problems.
Fingers crossed !!!
Bob
--
bob young
-
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 18192
MI-L C code resolved - SUM
Dear List Thanks to everybody who replied and in particular to Kris Woodland, Colin Henderson, John Williams and Warren Vick who conformed code ran OK on a variety of compilers. This knowledge lead to the resolution and so the MapInfo list resolved this problem before Microsoft - and the problem is with the Microsoft compiler ! By default I use the speed optimisation, on my release code, and in Visual Studio 6 this optimisation gets these twelve lines of code wrong! It does not think it needs to increment jCount while in the loop. I have turned off the optimiser just around this one function and now the code runs OK. Makes me wonder if I should turn off optimisation altogether ??!! Thanks again everyone. Regards Bob -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 18195
Re: MI-L smallest enclosing rectangular box
Hi Rinus If rotation angle can be anything, then what do you mean by Box. Do you mean smallest square, or rectangle with smallest area? Regards Bob In message <[EMAIL PROTECTED]>, Rinus Deurloo <[EMAIL PROTECTED]> writes >Dear all, > >Does any one know a fast algorithm for calculating the smallest enclosing >rectangular box around a region? I do not mean the MBR, because often this is >not the smallest, due to its fixed north-south orientation. I mean the box >that >is independent of orientation. > >Thanks in advance. > >Rinus Deurloo >University of Amsterdam >Dept. of Geography and Planning >The Netherlands. > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 18249 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 18256
Re: MI-L region object stats
Hi Eoin You can use Table - update column to add this information. First, I would recommend backing up your table in case you update incorrect columns. Then secondly use Table Maintenance to add extra columns for area, etc. Finally use Table - Update column to add information for each record. There are several functions such as area that can be used. The documentation in MapBasic is better than MapInfo for these functions. However you do not need to use MapBasic to make use of Update column. Regards Bob www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Eoin O'Mahony <[EMAIL PROTECTED]> writes >Is it possible to get a region's statistics, i.e. X and Y's, area etc >into a table without clicking on each one twice? I have just translated >an SHP file into MI6 and do not have this info in the source table. > >Thanks. > >Eoin O'Mahony >County Statistics Office >South Dublin County Council >County Hall >Tallaght >Dublin 24 > >Phone: 01 4149000 ex. 3345 >Fax: 01 4149106 >Web: www.southdublincounty.ie > > > > > > >* >The information in this email is confidential and may be legally privileged. >It >is intended solely for the addressee. Access to this email by anyone else is >unauthorised. If you are not the intended recipient, any disclosure, copying, >distribution or any action taken or omitted to be taken in reliance on it, is >prohibited and may be unlawful. If you have received this electronic message >in >error, please notify the sender or [EMAIL PROTECTED] This message has >been swept by Anti-Virus software. > > >* -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 18298
MI-L Minimum enclosing rectangle
Hi Rinus I've thought quite a bit about your requirement. I cannot think of a way to calculate the angle other than an iterative process. However such a process should be fairly straightforward, and also what computers are good at after all. Calculation of the enclosing rectangle for any given angle is fairly straight forward. The result whether you rotated the axiis by alpha or rotated the object by minus alpha would be the same. I would recommend the latter then the calculation is as simple as looping through each transformed node and getting min and max on each axis x .and y Having put this calculation in a function stage 2 would be to calculate area in a for next loop to get area for 0 degrees , 1 degree up to 359 degrees. Then depending on the accuracy required say first result returns 63 degrees as minimum then run calc from: 62.0 62.1 up to 63.9 in half degree steps. If this 62.6 do 62.51 to 62.69 etc until significant figure required is reached. Sounds cumbersome but it would be very quick on a computer. Hope this helps. Regards Bob www.MapsByDesign.co.uk -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 18300
Re: MI-L Tabbed shape file
Hi Tony In MapInfo 8.0, if you open up a native SHP file, MapInfo prompts you for a folder for the TAB, MAP and ID file. Therefore these can then be in a seperate folder to the SHP file. They are built "on the fly" each time you open the "TABBED" SHP. Your example of a TAB file seems to be missing a reference to the DBF file which is how MapInfo knows the SHP file is in a different folder to the TAB, DAT and ID. This then should allow SHP in readonly (eg CD) with TAB etc in writable folder. I hope this helps. If not please let me know and I will do a bit more investigation! Regards Bob In message <[EMAIL PROTECTED]>, Photogrammetry GIU <[EMAIL PROTECTED]> writes >Hi > >I recently had access to a "tabbed" shape file with the components >listed below, which failed to open. A message of "Unknown error" >appeared and then a browser came up. I tracked this down to the fact >that the folder the table was in was readonly (it could have been on a >CD or URL). > >1. Is there a setting in MI8 that allows MI to use the >designated temporary folder instead of trying (and failing) to create >the .map, .id and .dat components in the readonly file? >2. Is there a line that can be added to the metadata to tell >MI to use the temporary folder? > >The obvious current workaround is to copy all the components to a >folder where the readonly flag is not set. > >Tony > >File List: > >Some_Table.dbf >Some_Table.prj >Some_Table.sbn >Some_Table.sbx >Some_Table.shp >Some_Table.shx > >Some_Table.TAB > >!table >!version 700 >!charset WindowsLatin1 > >Definition Table > Type SHAPEFILE Charset "WindowsLatin1" > Fields 7 >Id_number Decimal (10, 0) ; >Name Char (240) ; >Registrati Date ; >Current_ca Char (10) ; >Easting Decimal (6, 0) ; >Northing Decimal (6, 0) ; >Area_ha Float ; >begin_metadata >"\IsReadOnly" = "FALSE" >"\Shapefile" = "" >"\Shapefile\PersistentCache" = "FALSE" >"\Spatial Reference" = "" >"\Spatial Reference\Geographic" = "" >"\Spatial Reference\Geographic\Projection" = "" >"\Spatial Reference\Geographic\Projection\Clause" = "CoordSys Earth >Projection 8, 79, ""m"", -2, 49, 0.9996012717, 40, -10 Bounds >(-7845061.1011, -15524202.1641) (8645061.1011, 4470074.53373)" >"\DefaultStyles" = "" >"\DefaultStyles\Pen" = "" >"\DefaultStyles\Pen\LineWidth" = "1" >"\DefaultStyles\Pen\LineStyle" = "0" >"\DefaultStyles\Pen\Color" = "255" >"\DefaultStyles\Pen\Pattern" = "2" >"\DefaultStyles\Brush" = "" >"\DefaultStyles\Brush\Pattern" = "52" >"\DefaultStyles\Brush\Forecolor" = "65280" >"\DefaultStyles\Brush\Backcolor" = "16777215" >end_metadata > > > >The e-mail and any files sent with it are private and intended solely for the >use of the person or body to whom they are addressed. If you are not the >intended recipient, you have received this in error and use of this >information >is prohibited. > >Nothing in the e-mail amounts to a legal commitment on our part unless >confirmed >by a signed communication. > >English Nature will make every effort to keep its network free of viruses. >However, you will need to scan this message/files for viruses as we can take >no >responsibility for any computer virus that might be transferred. > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 18355 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 18358
Re: MI-L Tabbed shape file
Hi Tony Sorry if I have the "wrong end of the stick" but I think MapInfo does do what you need now. The knack is to separate the TAB away from the SHP. Say you want your SHP files to be accessed from drive f ( ie READONLY ). Then copy just the TAB files to say "c:\SHPFiles\" ( which would be witeable) Then edit the TAB file. Just before the Type SHAPEFILE add a line File "f:\some_table.dbf" This pointer to the shape files DBF tells MapInfo where to find the SHP as well. However it will wrote its DAT,ID to where the TAB is. Regards Bob Regards Bob www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Photogrammetry GIU <[EMAIL PROTECTED]> writes > > >>>> Photogrammetry GIU 2005-10-18 10:53:51 >>> >Thanks Bob > >I agree that I can open a .shp file and be prompted to locate the >folder to dump the MI components into. >However it loses all the symbology data and appears in black and >white. > >The TAB file that came with the data contains in the metadata all the >symbology and projection data needed. >Hence the need to open the data set using the tab file provided. > >When I put the files into a write-access folder, the tab file works a >treat and I get nice red dotted objects, together with a temporary set >of .map, .id and .dat components which are deleted when the table is >closed. During the open sequence assorted status statements come up >showing the conversion process. This is a feature of MI from I believe 7 >onwards, but it needs to modified for MI8.1 et seq so that remote site >or CD data can be opened this way, ie MI checks that the folder (device) >is not readonly, and if it is, asks where to put the MI components, even >if it does delete them afterwards. I can always use a save as command >somewhere in the session. > >Tony > > > >>>> bob young <[EMAIL PROTECTED]> 2005-10-18 10:27:54 >>> >Hi Tony > >In MapInfo 8.0, if you open up a native SHP file, MapInfo prompts you >for a folder for the TAB, MAP and ID file. Therefore these can then be >in a seperate folder to the SHP file. They are built "on the fly" each >time you open the "TABBED" SHP. > >Your example of a TAB file seems to be missing a reference to the DBF >file which is how MapInfo knows the SHP file is in a different folder >to >the TAB, DAT and ID. This then should allow SHP in readonly (eg CD) >with >TAB etc in writable folder. > >I hope this helps. If not please let me know and I will do a bit more >investigation! > >Regards > > >Bob > > > >In message <[EMAIL PROTECTED]>, Photogrammetry GIU ><[EMAIL PROTECTED]> writes >>Hi >> >>I recently had access to a "tabbed" shape file with the components >>listed below, which failed to open. A message of "Unknown error" >>appeared and then a browser came up. I tracked this down to the fact >>that the folder the table was in was readonly (it could have been on >a >>CD or URL). >> >>1. Is there a setting in MI8 that allows MI to use the >>designated temporary folder instead of trying (and failing) to create >>the .map, .id and .dat components in the readonly file? >>2. Is there a line that can be added to the metadata to tell >>MI to use the temporary folder? >> >>The obvious current workaround is to copy all the components to a >>folder where the readonly flag is not set. >> >>Tony >> >>File List: >> >>Some_Table.dbf >>Some_Table.prj >>Some_Table.sbn >>Some_Table.sbx >>Some_Table.shp >>Some_Table.shx >> >>Some_Table.TAB >> >>!table >>!version 700 >>!charset WindowsLatin1 >> >>Definition Table >> Type SHAPEFILE Charset "WindowsLatin1" >> Fields 7 >>Id_number Decimal (10, 0) ; >>Name Char (240) ; >>Registrati Date ; >>Current_ca Char (10) ; >>Easting Decimal (6, 0) ; >>Northing Decimal (6, 0) ; >>Area_ha Float ; >>begin_metadata >>"\IsReadOnly" = "FALSE" >>"\Shapefile" = "" >>"\Shapefile\PersistentCache" = "FALSE" >>"\Spatial Reference" = "" >>"\Spatial Reference\Geographic" = "" >>"\Spatial Reference\Geographic\Projection" = "" >>"\Spatial Reference\Geographic\Projection\Clause" = "CoordSys Earth >>Projection 8, 79, ""m"", -2, 49, 0.9996012717, 40, -10 Bounds >>(-7845061.1011, -15524202.1641) (8645061.1011, 4470074.53373)&qu
Re: MI-L Importing MIF files
Hi Ali The Coordsys clause tells MapInfo what ellipsoid, datum, map projection and unit to use. This is particularly important when viewing two tables with different projections together. As MapInfo will know ellipsoids, projections etc for each layer it can transform each layer to a common projection to successfully "fit" these layers together. In the specific projection you question the units are metres, the ellipsoid is "Airey", the projection is Transverse Mercator, the true origin is -2, 49 the false origin is 400,000 metres west and 100,000 North of true origin the scale factor deployed is 0.9996012717 I would personally recommend you change your bounds clause to (0, 0) (20,2) This would set the tables internal step size to exactly 1 millimetre on both X and Y whereas the default values are approximately 6 mm and 9 mm. Using all these values would allow the data you put in the MIF file to line up with other layers also in BNG Map Projection. If you mistyped any values the layer would still look OK on its own in MapInfo but it would not then line up with other BNG layers. Regards Bob www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Ali Zolfaghari <[EMAIL PROTECTED]> writes >Hi list, >I am trying to import a mif file into mapinfo, but first I am learning on >how to create my mif file. Following is an example of some of beginning >lines of a mif file. Can anyone describe me what exactly line 4 means, line >stariting with CoordSys...? The projection is British National Grid. > >Thanks >Ali > > >Version 300 >Charset "WindowsLatin1" >Delimiter "," >CoordSys Earth Projection 8, 79, "m", -2, 49, 0.9996012717, 40, -10 >Bounds (-7845061.1011, -15524202.1641) (8645061.1011, 4470074.53373) >Columns 1 > HT Integer >Data > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 18374 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 18391
Re: MI-L Tabbed shape file
Hi Tony Following the points you raised it would be interesting to hear from the list how many members share the data between ESRI Clients and MapInfo clients. Presumably, although you only have read permissions to the SHP and TAB file other (ESRI) users have write permissions to the SHP file. I assume this because if all users see the file as readonly then the file might as well be converted once to MapInfo TAB and MapInfo users view that rather than rebuild MAP each time they open the file. Surely the benefit of not converting is to always link to the latest version of the SHP data when you open the file? So my question to the list is how many MapInfo users access SHP files that are being changed in realtime by other software packages? If your problem is that some users have write permissions to this file, but you only have read, then could you have write permissions to the folder, but read only to the SHP? This way you could create the MAP and ID files. I think your idea is a good suggestion for 8.1. If the TAB file is READ only then have a default path for creating temporary files would as you say solve the problem. If the SHP file was on a network drive it would also allow users to see the latest version of the SHP as they would build their own temporary DAT. What happens now?? Presumably if User A opens the Shaped TAB and stays on line User B picks up the MAP built by User A. But what happens when User A closes if User B is still on line...?? Any users with both MapInfo and ArcView and a network like to try that...? Regards Bob www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Photogrammetry GIU <[EMAIL PROTECTED]> writes >Thanks Bob > >It still does not get round the problem of data from remote sites where >if all you can see is .tab showing in the open table dialog, you have no >idea if there are shape files behind it unless you always open .tab >files with notepad in advance to check! The message of Unknown error or >internal error is certainly not going to remind you to look harder at >the data behind the tab. > >I still believe this is a bug in MI and needs fixing, otherwise the >faith of the community in MI tab files will be affected. > >Tony > >>>> bob young <[EMAIL PROTECTED]> 2005-10-18 12:05:26 >>> >Hi Tony > >Sorry if I have the "wrong end of the stick" but I think MapInfo does >do >what you need now. > >The knack is to separate the TAB away from the SHP. Say you want your >SHP files to be accessed from drive f ( ie READONLY ). > >Then copy just the TAB files to say "c:\SHPFiles\" ( which would be >witeable) > >Then edit the TAB file. Just before the > >Type SHAPEFILE > > >add a line >File "f:\some_table.dbf" > > > >This pointer to the shape files DBF tells MapInfo where to find the >SHP >as well. However it will wrote its DAT,ID to where the TAB is. > >Regards > > >Bob > > > > >Regards > > >Bob >www.MapsByDesign.co.uk > > > >In message <[EMAIL PROTECTED]>, Photogrammetry GIU ><[EMAIL PROTECTED]> writes >> >> >>>>> Photogrammetry GIU 2005-10-18 10:53:51 >>> >>Thanks Bob >> >>I agree that I can open a .shp file and be prompted to locate the >>folder to dump the MI components into. >>However it loses all the symbology data and appears in black and >>white. >> >>The TAB file that came with the data contains in the metadata all the >>symbology and projection data needed. >>Hence the need to open the data set using the tab file provided. >> >>When I put the files into a write-access folder, the tab file works a >>treat and I get nice red dotted objects, together with a temporary >set >>of .map, .id and .dat components which are deleted when the table is >>closed. During the open sequence assorted status statements come up >>showing the conversion process. This is a feature of MI from I believe >7 >>onwards, but it needs to modified for MI8.1 et seq so that remote >site >>or CD data can be opened this way, ie MI checks that the folder >(device) >>is not readonly, and if it is, asks where to put the MI components, >even >>if it does delete them afterwards. I can always use a save as command >>somewhere in the session. >> >>Tony >> >> >> >>>>> bob young <[EMAIL PROTECTED]> 2005-10-18 10:27:54 >>> >>Hi Tony >> >>In MapInfo 8.0, if you open up a native SHP file, MapInfo prompts you >>for a folder for the TAB, MAP and ID file. Therefore these can then >be >>in a seperate folder to the SHP file. They are built "on the fly" >each >>tim
[Mapinfo-l] Does Oracle store as integer or floating point?
Hi list, Very good to see we are up and running again! I have been trying to find out if Oracle Spatial stores X and Y coordinates as double precision numbers like ESRI SHP file, or as integer numbers times a floating point step size as within native MapInfo TAB format. I could not get an answer at our AGI event, and am therefore throwing the question out to the list. My expectation is that they store as integer, because apparently a bounds clause needs to be specified for each table. Is this correct ? Regards Bob Young MapsByDesign.co.uk -- bob young ___ Mapinfo-l mailing list Mapinfo-l@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
[Mapinfo-l] Does Oracle Spatial store integer or floating point?
Hi list, Very good to see we are up and running again! I have been trying to find out if Oracle Spatial stores X and Y coordinates as double precision numbers like ESRI SHP file, or as integer numbers times a floating point step size as within native MapInfo TAB format. I could not get an answer at our AGI event, and am therefore throwing the question out to the list. My expectation is that they store as integer, because apparently a bounds clause needs to be specified for each table. Is this correct ? Regards Bob Young MapsByDesign.co.uk -- bob young ___ Mapinfo-l mailing list Mapinfo-l@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MapInfo-l] MapInfo-L Blackout
Hi Bill The MapInfo User Group for Ireland and UK is fairly active (www.muguki.com), and in fact a question was asked here regarding problems with MapInfo-L. Perhaps this could be used as a temporary place for postings if MapInfo - L goes down. How about it Martin ? Regards Bob @www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Bill Thoen <[EMAIL PROTECTED]> writes >Sounds like the "One List" party here is in the majority. Well, okay, but >my point was more about how do we carry our eggs in more than one basket. >Our entire communications capability depends on one server over which none >of us have any control. Not that this is so bad; Directions Magazine is a >dedicated player in the GIS community and so their interests generally >align with ours and also they have the online resources and expertise to >maintain a pretty good service for only the price of using our content as a >background to display advertising. But it's still only one link and if it >gets cut, there's no backup. My suggestion for a second list was more to >justify setting up a parallel service operated from a different server >located somewhere else on the 'net. > >But there are other ways to spread out the presnece without thinning out >the content. For example, I'd really love to see someone set up a MapInfo >wiki. I tried to set one up a few years ago, but didn't have the >infrastructure or the expertise to maintain it, and the hackers destroyed >it before I could get it going. Then I worked with Eric Frost to set up >another one, but that never got off the ground for pretty much the same >reasons. > >I think at least I'm going to set up a small MapInfo-L news page on my web >site so that there will be at least one place people can go to find out >what's happening, should anything out of the ordinary happen. More on that >later... But if anyone has any ideas about how we can be less dependent on >only one service, let's talk about it. > >- Bill Thoen > >_______ >Mapinfo-l mailing list >Mapinfo-l@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ Mapinfo-l mailing list Mapinfo-l@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [Mapinfo-l] GPS Geotrack and British National Grid
Dear Oliver We have transformation from WGS84 to BNG built into out Pocket PC software. If you are unable to get a solution, we could package this code into an MBX for use within MapInfo for you. We have also built in OSTN02 correction so you will get an exact match to the GPS.GOV.UK website run by Ordnance Survey. This uses a table of corrections published by Ordnance Survey. If you want to see the accuracy you would achieve there is a full evaluation copy of Maps4Site on our website. Regards Bob @www.MapsByDesign.co.uk Oliver Francis <[EMAIL PROTECTED]> writes > >Hello all, > > > > > >We have recently acquired 2 GPS antenna (Fortuna U2) that we intend on >using with our toughbooks whilst carrying out fieldwork. > > > >I have managed to get them up and running in MapInfo 7.8 Pro using >GeoTrack. The problem however is that our maps are based on British >National Grid. I've checked the online discussion group (Blue Marble >Geographics) and found that it is not possible to display GPS data in >Northings and Eastings. > > > >Can anyone think of a possible solution to my problem? > > > >Many thanks > > > > > > > >Oliver Francis > > > > > >GIS Operator > >Maidstone Borough Council > >- > >I.T. Block B > >13 Tonbridge Road > >Maidstone > >ME16 8HG > >UK > >- > >tel: + 44 (0)1622 602438 > >[EMAIL PROTECTED] > ><http://www.digitalmaidstone.co.uk/> > > > > > > > >Please complete our online survey and help us to improve our services to you: > >http://www.digitalmaidstone.co.uk/customersurvey/ > >This email is confidential. If you receive it by mistake, please advise the >sender by email immediately. Any >unauthorised use of the message or attachments is prohibited. Unless stated >otherwise, any opinions are personal >and cannot be attributed to Maidstone Borough Council. This email is not a >contract or an order. It is your >responsibility to carry out virus checks before opening any attachment. > >www.digitalmaidstone.co.uk___ >Mapinfo-l mailing list >Mapinfo-l@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ Mapinfo-l mailing list Mapinfo-l@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [Mapinfo-l] FW: GPS Geotrack and British National Grid
Hi Tim I absolutely agree that MapInfo has got great features for reprojecting. However the method you outline will only position a user within about five or six metres of where they really are. With low cost GPS, the GPS psoition too will only be within 3 to 10 metres but the combined affect is a bigger error, as the two sets of errors are for different reasons. If a user has more accurate GPS, and there are a few sub metre solutions around, then the solution you propose, which will not include OSTN02 correction will not be good enough for the investment made in the GPS. The OSTN02 corrections ( see GPS.GOV.UK ) will give corrections to three decimal places of a metre. With the very accurate GPS systems available this accuracy is a requirement. It is fairly easy to prove this. You can draw in some lines with chosen lat long, then use MapInfo to reproject as you suggest, and note down the Easting, Northing MapInfo computed. Now submit the same lat, longs to GPS.GOV.UK and you will see you get values fve or six metres different. The reason for this is that MapInfo uses a mathematical model to move from one system to another. British National Grid as used in MasterMap has been based on County Series Maps and the only way to adjust to these from WGS84 is to use the published figures which Ordnance Survey have kindly made available free of charge for use by developers and users on their website. Regards Bob Tim Rideout <[EMAIL PROTECTED]> writes > >Dear Oliver, > >I don't see what the problem is. Import the stuff into MapInfo as decimal >degrees in Lat / Long WGS 84. MapInfo will then automatically reproject your >data on the fly into GB National Grid if you simply add the GPS tab file >into your National Grid map window. You can use the 'Save As' and click the >projection button if you want to permanently convert it to GB National Grid. > >It is one of the things about MapInfo and the Tab format. All tables must >declare their projection parameters so MapInfo always knows what these are >for any particular table. Thus for any map window it can detect the >projection used in that window, the incoming projection for any table you >are trying to add to that window, and thus arrange for the automatic >reprojection for display purposes. You don't even need to think about it - >it just happens. > >Try that in ArcView 3! > >If anyone isn't sure they know everything about MapInfo that they would like >to know, then you are welcome to look at our training course outline and >particulars at www.xyzmaps.com. The prices are pretty reasonable and we >cover a lot of ground. > >regards > >Tim > > > >Dr Tim Rideout >Director > >Visit XYZ at the AGI Scotland Event in Edinburgh on December 1st. > >The XYZ Digital Map Company >Unit 9 Phase 2 Hardengreen Business Park >Dalhousie Road >Dalkeith Scotland EH22 3NX > >Tel +44 131 454 0426 > >Fax +44 131 454 0443 > >Mobile + 44 7766 825937 > >E-mail [EMAIL PROTECTED] > > > > > _ > >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Oliver >Francis >Sent: 15 November 2005 09:23 >To: mapinfo-l@lists.directionsmag.com >Subject: [Norton AntiSpam] [Mapinfo-l] GPS Geotrack and British National >Grid > > > >Hello all, > > > > > >We have recently acquired 2 GPS antenna (Fortuna U2) that we intend on using >with our toughbooks whilst carrying out fieldwork. > > > >I have managed to get them up and running in MapInfo 7.8 Pro using GeoTrack. >The problem however is that our maps are based on British National Grid. >I've checked the online discussion group (Blue Marble Geographics) and found >that it is not possible to display GPS data in Northings and Eastings. > > > >Can anyone think of a possible solution to my problem? > > > >Many thanks > > > > > > > >Oliver Francis > > > > > >GIS Operator > >Maidstone Borough Council > >- > >I.T. Block B > >13 Tonbridge Road > >Maidstone > >ME16 8HG > >UK > >- > >tel: + 44 (0)1622 602438 > >[EMAIL PROTECTED] > > <http://www.digitalmaidstone.co.uk/> > > > > > >Please complete our online survey and help us to improve our services to >you: > >http://www.digitalmaidstone.co.uk/customersurvey/ > >This email is confidential. If you receive it by mistake, please advise the >sender by email immediately. Any >unauthorised use of the message or attachments is prohibited. Unless stated >otherwise, any opinions are personal >and cannot be attributed to Maidstone Borough Council. Th
Re: [Mapinfo-l] FW: GPS Geotrack and British National Grid
gh Council > >- > >I.T. Block B > >13 Tonbridge Road > >Maidstone > >ME16 8HG > >UK > >- > >tel: + 44 (0)1622 602438 > >[EMAIL PROTECTED] > ><http://www.digitalmaidstone.co.uk/> > > > > > >Please complete our online survey and help us to improve our services to >you: > >http://www.digitalmaidstone.co.uk/customersurvey/ > >This email is confidential. If you receive it by mistake, please advise >the sender by email immediately. Any >unauthorised use of the message or attachments is prohibited. Unless >stated otherwise, any opinions are personal >and cannot be attributed to Maidstone Borough Council. This email is not >a contract or an order. It is your >responsibility to carry out virus checks before opening any attachment. > >www.digitalmaidstone.co.uk > > > > > >Please complete our online survey and help us to improve our services to you: > >http://www.digitalmaidstone.co.uk/customersurvey/ > >This email is confidential. If you receive it by mistake, please advise the >sender by email immediately. Any >unauthorised use of the message or attachments is prohibited. Unless stated >otherwise, any opinions are personal >and cannot be attributed to Maidstone Borough Council. This email is not a >contract or an order. It is your >responsibility to carry out virus checks before opening any attachment. > >www.digitalmaidstone.co.uk___ >Mapinfo-l mailing list >Mapinfo-l@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ Mapinfo-l mailing list Mapinfo-l@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [Mapinfo-l] FW: GPS Geotrack and British National Grid
Hi Tim I see where you're coming from, but that is indeed the sort of correction OSTN02 supplies ie about 120 metres and varying from 1 km square to the next. The reason MapInfo appears to be about six metres out is they have "averaged out" the OSTN02 correction. The correct transformation is a mathematical formula from WGS84 Lat Long to the theoretical datum used for BNG. Then as a second stage apply the error corrections ie approx. 120 metres as supplied in OSTN02.( MapInfo does NOT do this ). MapInfo I suggest also applies two stages. The first is the same mathematical adjustment to our datum. The second is some algorithm that does an average. This will reduce the 120 metre type figure to about six metres. The reason Oliver is getting 120 metres I think is he is using the theoretical projection, and so MapInfo has only applied the first stage. I am a bit rusty on the correct terms, datums etc for stage 1 and 2 as I wrote our adjustments a couple of years ago. However at that time I did a lot of testing in this area. If there's any general interest in this perhaps it could also form a part of the SIG already proposed for the bounds clause. Regards Bob Tim Rideout <[EMAIL PROTECTED]> writes > >Dear Bob, > >Yes I realise this. However I have also heard from Oliver that the error is >over 150 metres, so there is something much more fundamental. I suspect >maybe the projection or datum has been set incorrectly when the data was >loaded. > >Regards > >Tim > >Dr Tim Rideout >Director > >Visit XYZ at the AGI Scotland Event in Edinburgh on December 1st. > >The XYZ Digital Map Company >Unit 9 Phase 2 Hardengreen Business Park >Dalhousie Road >Dalkeith Scotland EH22 3NX > >Tel +44 131 454 0426 > >Fax +44 131 454 0443 > >Mobile + 44 7766 825937 > >E-mail [EMAIL PROTECTED] > > >-Original Message- >From: bob young [mailto:[EMAIL PROTECTED] >Sent: 15 November 2005 12:53 >To: [EMAIL PROTECTED] >Cc: mapinfo-l@lists.directionsmag.com >Subject: Re: [Mapinfo-l] FW: GPS Geotrack and British National Grid > >Hi Tim > >I absolutely agree that MapInfo has got great features for reprojecting. > >However the method you outline will only position a user within about five >or six metres of where they really are. With low cost GPS, the GPS psoition >too will only be within 3 to 10 metres but the combined affect is a bigger >error, as the two sets of errors are for different reasons. > >If a user has more accurate GPS, and there are a few sub metre solutions >around, then the solution you propose, which will not include OSTN02 >correction will not be good enough for the investment made in the GPS. > >The OSTN02 corrections ( see GPS.GOV.UK ) will give corrections to three >decimal places of a metre. With the very accurate GPS systems available this >accuracy is a requirement. > >It is fairly easy to prove this. You can draw in some lines with chosen lat >long, then use MapInfo to reproject as you suggest, and note down the >Easting, Northing MapInfo computed. Now submit the same lat, longs to >GPS.GOV.UK and you will see you get values fve or six metres different. > >The reason for this is that MapInfo uses a mathematical model to move from >one system to another. British National Grid as used in MasterMap has been >based on County Series Maps and the only way to adjust to these from WGS84 >is to use the published figures which Ordnance Survey have kindly made >available free of charge for use by developers and users on their website. > >Regards > > >Bob > > > > > >Tim Rideout <[EMAIL PROTECTED]> writes >> >>Dear Oliver, >> >>I don't see what the problem is. Import the stuff into MapInfo as >>decimal degrees in Lat / Long WGS 84. MapInfo will then automatically >>reproject your data on the fly into GB National Grid if you simply add >>the GPS tab file into your National Grid map window. You can use the >>'Save As' and click the projection button if you want to permanently >convert it to GB National Grid. >> >>It is one of the things about MapInfo and the Tab format. All tables >>must declare their projection parameters so MapInfo always knows what >>these are for any particular table. Thus for any map window it can >>detect the projection used in that window, the incoming projection for >>any table you are trying to add to that window, and thus arrange for >>the automatic reprojection for display purposes. You don't even need to >>think about it - it just happens. >> >>Try that in ArcView 3! >> >>If anyone isn't sure they know everything about MapInfo that they would >>like to kno
Re: [MI-L] Max file size in mapinfo
Hi Sasidhar Maximum size for MAP file is 2 GB and maximum size for DAT file is 2 GB. Whichever you hit first will limit your layer size. If you have a lot of data attribution you may fill DAT first. If not you might fill MAP ( geometry ) first. One way round the problem is to use MapInfo seamless layers. Break your area of interest down into smaller rectangles. For example if your 15 million records cover 1000 km x 1000 km split into 100 squares of 100 km x 100 km. Then create a seamless layer over the 100 base tables. Regards Bob In message <[EMAIL PROTECTED]>, Sasidhar <[EMAIL PROTECTED]> writes >HI all > >i have a huge data in oracle spatial(40 million records).this data >is to be expoted to mapinfo tab files. > >currently, we worked easily with 1.5 GB tab files# > >what could be the problems/efficiency if above data (expecting a 15 >GB tab file) has to be used in mapinfo tab files. > >please let me know if there are any limitations/alternatives for >faster access > >Thanks > >Sasidhar > >___ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Discover Mobile hardware
Hi Brendan I'm not familiar with the software you mention. However if it runs on Pocket PC then I would highly recommend the Hewlett Packard HX4700. Combined with an Otter case you can use in all weathers. The screen is 4 inches diagonal, so slightly larger than normal. However it appears even bigger when running in VGA mode. With 640 x 480 it is very sharp and bright, particularly when viewing raster eg aerial photography. Battery life is good. You can also buy an "extended battery" for it. It has bluetooth for easy connection to GPS. It has two expansion slots, CF and SD. I have a 4GB CF card and a 2 GB SD card in mine so can take out 6 GB of MapInfo tables and/or ECW raster. It costs about £300 ( sterling ) with the two cards adding approx a further £250. The otter case is about £70. If you need to send and receive data then the new Orange M5000 is also an excellent choice. However this is not so easy to "ruggedise" as to make use of the fold out keyboard, you cannot use the Otter case. Great in fine weather. The addition of ZIP( creation and extraction ) and the PDF viewer are great additions to Mobile 5.0 that comes with the Orange M5000. The screen again is 640 x 480 and is really bright. When you get used to the VGA the older 320 x 240 appears a bit fuzzy. The Dell 51v is also VGA but I have not tried one of these. Regards Bob @MapsByDesign.co.uk In message <[EMAIL PROTECTED] liden.com>, Brendan O'Donovan writes >Hi all, > >I am contemplating buying Encom's Discover Mobile, primarily for >geological mapping but also with an eye to mineral exploration in general. >I have had good advice from various vendors regarding appropriate hardware >but would welcome advice from anyone actually using the software wrt >hardware selection. > >Regards Brendan O'Donovan >___ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Field Types
Hi Andrew The floating point (float) which is double precision holds numbers to "at least 15 digits of precision". This quote is from Microsoft Visual Studio help. I would have thought this is a bit too close to your requirement though, and that you would be better holding the numbers as a character string. If you need to convert the string to a number, again you are close to the specification for a double and might not maintain this accuracy. However that is a lot of significant figures! You can use the MapBasic format command to print out more than six decimal places for a double precision number. Hope this helps. Regards Bob @www.MapsByDesign.co.uk Andrew Tracey <[EMAIL PROTECTED]> writes >Dear All > >I have a table containing 68000 records, which has a column, which should have >a >value to 15 decimal places, when I import the data it seems to truncate to 6 >decimal places, is there any way of creating a field, which would hold the 15 >decimal places? > >Thanks in advance > >Andrew Tracey >Information Support Officer >Corporate Information >Corporate Development >South Tyneside Council >Westoe Road >South Shields >NE33 2RL > >Tel: 0191 4247561 >E-Mail : [EMAIL PROTECTED] > > > > > >Please do not print this e-mail if you can help it - and help protect the >environment. > > >This Message may contain confidential information and is protected by >copyright. >If you receive it in error please notify us and delete it without making use >of >or copying it. >The addressee and other employees within the Council may read and copy any e- >mail >reply to this message and other e-mails you send to us. >Whilst we use virus checking procedures we accept no liability for viruses and >recipients >must rely on their own virus checking procedures. > > >The Council's web site address is www.southtyneside.info > >_______ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] MapInfo and ArcGIS Comparison
Hi Flavio, Lars and Andrew I absolutely agree with Flavio and Andrew regarding the format. > >> MapInfo has the better data format (see my other mail to Lars) >Has it ? What objective argument leads you to that conclusion ? If you're >referring to the ability of the TAB format to hold multiple topography, I >find that to be mostly irrelevant, 1) since most use the tables for >single-topography data anyway, and 2) most users are annoyed by the >horrendeous old fashioned file system dependency compared to todays >standards. I guess we all "specialise" and use MapInfo in different ways. However Andrew comes from a sector that is very significant for any GIS vendor such as MapInfo and ESRI, I believe it represents something like 40% of UK sales. For any public sector organisation in Britain that uses Ordnance Survey data MapInfos data format towers over ESRI. The great,great shame is that even MapInfo do not market this advantage. Native MapInfo will comfortably hold a local authorities data, and render it very quickly to the screen. ESRIs native formats will not. The big big difference is the RTREE spatial index employed, meaning only the information thats needed on screen is read from the disk drive. I would suggest that for most Local Authorities Oracle Spatial is an unnecessary overhead - but is an essential component for any ESRI solution. Regards Bob @MapsByDesign.co.uk ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Shifting Data to more "open" spatial access?
to his >manufacturing/accounting Oracle database might be leaving these new and >future $$$ opportunities on the desk? > >I am not certain I am looking for excoriation rites or a hate-debate but >one based in the real opportunities - the bigger benefits the Oracle >Spatial design could provide. It's a benefit/cost thing - pick your >quill. > >Thanks >MidNight Mapper >Aka neil > >___ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: MI-L Table creation date
HI Larry I'm pretty sure it does not keep date anywhere. However you could do this yourself on your own data by creating a field in the metadata in the tab file. Regards Bob #essage <[EMAIL PROTECTED]>, Larry Nolan <[EMAIL PROTECTED]> writes > >Does anyone know if Mapinfo stores the date a table was created. If it does >do you know of a way using Mapbasic to retrieve it. I know I can use the >windows API functions to get the date/time stamp of the files on the disk >but that will only give me the date last edited or the last time opened by >Mapinfo. > >Thanks > >Larry Nolan >Data Solutions >[EMAIL PROTECTED] >http://solutionsgroup.tripod.com - free Mapinfo utilities > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MI-L Changes to MapInfo-L mail server
R ead T he M anual plus a bit of imagination ! Bob In message <002901c1d412$cc10fdd0$d317ad90@DELLRSDIBLEY>, Richard Dibley <[EMAIL PROTECTED]> writes >I'm using Outlook and my filtering of MI-L messages is unaffected - it >still works fine. I filter based on the inclusion of MI-L in the >subject line. You could try re-creating the filter > >Don't panic! > >Richard > >+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + >+ + + + >Richard Dibley, Consultant >CSMA Consultants Ltd, Trevenson, Pool, Redruth, Cornwall, TR15 3SE > >Tel +44 (0)1209 717724, Fax +44 (0)1209 710893, Mobile +44 (0)7968 >730418 > >E-mail [EMAIL PROTECTED] Web www.csmaconsultants.com >+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + >+ + + + > > >-Original Message- >From: Woody Woodruff [mailto:[EMAIL PROTECTED]] >Sent: 25 March 2002 12:15 >To: Mapinfo List; Bill Thoen >Subject: RE: MI-L Changes to MapInfo-L mail server > > >Whatever is going to happen to the list administratively, I am concerned >that it will not be the way it behaves recently with Microsoft Outlook. >Right now, all mail coming from the list is seen as from the individual, >it will no longer sort into the Mapinfo List Folder, it all stays in the >inbox. It used to all go into that folder. Now I have to physically >move the 30+ msgs the list generates a day. It is a minor pain, but >there is a chance that other mail will inadvertently be dragged manually >into the folder. If this is simply a problem on my end, I don't know >how to fix it, I have tried. Any suggestions? Please don't conceder >this panic, just want to be sure it will function with Outlook. Well, >ok, maybe it's a little panicky. and what is RTFM? > >William "Woody" Woodruff >Zoning Administrator >Charter Township of Union, Isabella County, Michigan >(989) 772 4600 EXT 41 >Visit our web site at http://www.geocities.com/ctuzoning/index.htm > > >-Original Message- >From: Bill Thoen [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, March 20, 2002 12:14 PM >To: MapInfo-L >Subject: MI-L Changes to MapInfo-L mail server > > >The software we've been using to manage the MapInfo-L mailing list has >been (or soon will be) retired. The new software is called EZMLM, and >you can get info on it at http://www.ezmlm.org. It's a little different >(and looks lots better), so don't be surprised when old procedures >you're used to don't work. > >As soon as the changeover is completed, we'll all get the news and new >instructions posted here on the list. You don't have to do anything yet >except keep watching for the notice. > >So when things change, don't panic. Just RTFM. > >-- >- Bill Thoen > >GISnet, 1401 Walnut St., Suite C, Boulder, CO 80302 >tel: 303-786-9961, fax: 303-443-4856 >mailto:[EMAIL PROTECTED], http://www.gisnet.com > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MI-L Changes to MapInfo-L mail server
Hi Richard Hope it was clear the explanation of "What is RTFM" was an answer to Woodys question within your email, and not meant for you! I should have edited the message a bit! Cheers Bob In message <002901c1d412$cc10fdd0$d317ad90@DELLRSDIBLEY>, Richard Dibley <[EMAIL PROTECTED]> writes >I'm using Outlook and my filtering of MI-L messages is unaffected - it >still works fine. I filter based on the inclusion of MI-L in the >subject line. You could try re-creating the filter > >Don't panic! > >Richard > >+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + >+ + + + >Richard Dibley, Consultant >CSMA Consultants Ltd, Trevenson, Pool, Redruth, Cornwall, TR15 3SE > >Tel +44 (0)1209 717724, Fax +44 (0)1209 710893, Mobile +44 (0)7968 >730418 > >E-mail [EMAIL PROTECTED] Web www.csmaconsultants.com >+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + >+ + + + > > >-Original Message- >From: Woody Woodruff [mailto:[EMAIL PROTECTED]] >Sent: 25 March 2002 12:15 >To: Mapinfo List; Bill Thoen >Subject: RE: MI-L Changes to MapInfo-L mail server > > >Whatever is going to happen to the list administratively, I am concerned >that it will not be the way it behaves recently with Microsoft Outlook. >Right now, all mail coming from the list is seen as from the individual, >it will no longer sort into the Mapinfo List Folder, it all stays in the >inbox. It used to all go into that folder. Now I have to physically >move the 30+ msgs the list generates a day. It is a minor pain, but >there is a chance that other mail will inadvertently be dragged manually >into the folder. If this is simply a problem on my end, I don't know >how to fix it, I have tried. Any suggestions? Please don't conceder >this panic, just want to be sure it will function with Outlook. Well, >ok, maybe it's a little panicky. and what is RTFM? > >William "Woody" Woodruff >Zoning Administrator >Charter Township of Union, Isabella County, Michigan >(989) 772 4600 EXT 41 >Visit our web site at http://www.geocities.com/ctuzoning/index.htm > > >-Original Message- >From: Bill Thoen [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, March 20, 2002 12:14 PM >To: MapInfo-L >Subject: MI-L Changes to MapInfo-L mail server > > >The software we've been using to manage the MapInfo-L mailing list has >been (or soon will be) retired. The new software is called EZMLM, and >you can get info on it at http://www.ezmlm.org. It's a little different >(and looks lots better), so don't be surprised when old procedures >you're used to don't work. > >As soon as the changeover is completed, we'll all get the news and new >instructions posted here on the list. You don't have to do anything yet >except keep watching for the notice. > >So when things change, don't panic. Just RTFM. > >-- >- Bill Thoen > >GISnet, 1401 Walnut St., Suite C, Boulder, CO 80302 >tel: 303-786-9961, fax: 303-443-4856 >mailto:[EMAIL PROTECTED], http://www.gisnet.com > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MI-L Angle of sun
Dear List Can anybody please point me in the direction of formulae or a website to allow computation of the two angles for direction of shadow from sun and also length of shadow from sun at different times of the day/year and at different long/lat or better still at British National Grid and relative to North on BNG. I'd like to be able to compute the bearing of a line from the sun and pretty accurately. Can anybody comment on the accuracy that can be achieved if the exact location and time are known? I'm comparing bearings derived from MasterMap data with measured angles on site ( long shots to trig points ) and would like to include bearings computed from sun in comparisons. Any titles of books on this subject would be much appreciated. Thanks for any help. Regards Bob -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MI-L OLE Server Problems with mapinfow.exe
In message <[EMAIL PROTECTED]>, Michael Martinson <[EMAIL PROTECTED]> writes Hi Michael Yes, you just need to send the MB statement "Set ProgressBars Off and this will stop the MapInfo "out of process" exe causing the switch to... In VB MI.do "Set ProgressBars off" On A similar issue however it is well documented by Microsoft that an exe calling an EXE as an out of process exe that then calls a modal dialog box will also cause this switch to When you send MI OLE object "Set Application Window" it manages to reparent its dialog boxes, of which many are modal, to the out of process exe. Anybody out there know what API calls allow one exe to reparent another exes modal windows as MI achieves? Regards Bob >Hello, > >I've tried looking in my own archives of the list (from December of 2001) >but I couldn't find an answer for this problem. > >I'm using an OLE server programmed via MapBasic (6.5 across the board for >mapinfo products) from Visual C++. I init OLE, start up the mapinfo >dispatch and then commence to make thematic maps. The whole process will >go through, but during the creation of the thematic map, the progress >dialog will pop up, first with a 'combining objects' then with >'interpolating'. Between the two popups (after combining but before >interpolating), the main dialog box of the program gets a popup dialog with >the following: >Title: Server Busy >Text: The action cannot be completed because the other program is >busy. Choose "Switch To" to activate the busy program and correct the problem. >Buttons: Switch To..., Retry, and (a grayed out) Cancel. > >The popup dialog won't let the next statement of the MapBasic go through, >or I wouldn't even worry about it. > >Is there any way to turn off the progress dialogs, or turn off whatever >command comes back between the progress dialogs, or something else I'm >missing to get rid of the 'Server Busy' popup? > >This program needs to run stand alone (it's intended to replace about 40 >minutes of time which could be otherwise used productively, but if you have >to hit the 'retry' continuously, you might as well have used the regular >process to create the maps by hand...) > >Michael > >-- >Michael Martinson >Software Engineer >DTN > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MI-L Ski Resort Mapping
Hello David Unfortunately not. However as a keen skier I'd ask you to try and include Cardiff Airport and Bristol Airport from this end!! A late flight Friday out, and a late Sunday night return would be just the ticket! Good luck with the data. Bob Young By Design In message <[EMAIL PROTECTED] e.local>, David Bell <[EMAIL PROTECTED]> writes >Does anyone know of, or have,data on ski resorts within Europe (Alpes). I need >to analyse them but I'm unable to find coordinates. > > > > <http://hotbar.com/scripts/utils/bcLogo.asp> > >David Bell >Network Growth Manager >Go-Fly Ltd. > > >Enterprise House, Stansted Airport, >Essex CM24 1SB >+44 (0) 1279 668 012 > > >[EMAIL PROTECTED] www.go-fly.com <http://www.go-fly.com/> > > > <http://hotbar.com/images/null.gif> > <http://hotbar.com/images/null.gif><http://hotbar.com/images/null.gif> > <http://hotbar.com/accounts/services/bcards/GetLatestCard.asp?card_Data=18042,8 >27809341,4> > <http://hotbar.com/accounts/services/bcards/Contact.Vcf?card_Data=18042,8278093 >41,4> Add this card to your address book > > > _ > > <http://hotbar.com/Scripts/Utils/ShineDirect.asp?requestor=shn22> Upgrade >Outlook - Add COLOR to your Emails <http://hotbar.com/Scripts/Utils/Shine >Direct.asp?requestor=shn22> >----- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MI-L C and MapInfo
Hi Ben I use C a lot with MapInfo. I use C DLLs where speed is of the essence. It coordinates well with both MapBasic code and with VB code. I personally don't use it for any forms or user controls. Normally the GUI is VB or MapBasic and C for the number crunching. So I would recommend adding C to your languages for GIS. Regards Bob mapsbydesign.co.uk In message <[EMAIL PROTECTED]>, Ben Crane <[EMAIL PROTECTED]> writes >Hi list, > >Just a quickie for advice...I have a some knowledge of >C/C++, it's mainly self-taught with no formal >qualifications. I am signing up for a C course in >September which is 36 weeks long and should give me >the formal background I need. But one question, how >feasible/useful is C with GIS systems (in particular >MapInfo)? I am working through VB and am almost >finished an advanced course...but I feel I need to add >more programming languages...the real reason for c is >based more on cost than anything else (that and >previous experience with it)... > >Are there any other general/powerful languages that >should be seriously considered for GIS programming?? I >understand Java/C++/Delphi are popular--but would C be >really advantageous!? > >Thanx >Ben > >__ >Do You Yahoo!? >Yahoo! Autos - Get free new car price quotes >http://autos.yahoo.com > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MI-L OS Mastermap - Oracle Spatial
Dear David By Design are MapInfo Premier Partners and have developed a MasterMap Translator for MasterMap data. Our translator MapGML runs as two seperate processes. The first takes OS initial and update chunks as GZ files and maintains a local holding. Stage 2 is a publishing stage which produces output for users from the central holding. We can currently write to AutoCAD and to MapInfo and would be interested in looking at other formats. Publishing includes options for styling and for publishing by an area of interest or complete coverage. I guess the stage 1 output is what you would be most interested in where you are wanting to publish to four formats. I am quite happy to discuss this in detail if you would like to ring me. If you or any customers would be interested in an evaluation copy please email me or give me a ring on 01633 881117 and we can send you/them copies. We are holding seminars in Newport, Windsor, London and Southampton on MasterMap and our solutions during September and October. For anybody interested in attending please contact By Design. Bob Young By Design www.mapsbydesign.co.uk Tel (0044) 1633 881117 In message <8B2C45B3CF1CD611B93B000347087051329038@SGBBMB2001>, Eagle, David A <[EMAIL PROTECTED]> writes >Listers, > >A client of ours is looking to utilise the new OS Mastermap data that has >superseded OS Landline. They have purchased some initial data but ultimately >will purchase UK coverage. MapInfo is one of their GIS packages but they >also use three others. Ideally it would be useful to store the data in one >central location so that all 4 applications can draw off it, that way we >minimise storage requirements and only one set of data need receive updates. > >I am beginning to research the use of databases and Oracle in particular but >am finding it a difficult minefield to navigate through given my database >knowledge (v. minimal). Can anyone share any experiences (or solutions) of >similar issues relating to Mastermap or database use in general (with >MapInfo or others). Mastermap is delivered in GML (Geographic Markup >Language) format which should make multi application use through a database >more feasible, however, my understanding of how MapInfo and other >applications would access the data is also limited. > >Any thoughts greatly appreciated. >Rgds, Dave > >-- >David A. Eagle >GIS Consultant > >Atkins Design Environment >& Engineering >Cornerstone House >Stafford Park 13, Telford >Shropshire, TF3 3AZ >England >Tel: +44 (0)1952 21 3268 * >Fax: +44 (0)1952 20 0981 * > >Email: [EMAIL PROTECTED] * >Web: www.atkinsglobal.com* > > > > > >This email and any attached files are confidential and copyright protected. >If you are not the addressee, any dissemination of this communication is >strictly prohibited. Unless otherwise expressly agreed in writing, nothing >stated in this communication shall be legally binding. > > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 2253 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2280
Re: MI-L MB: Fastedit on?
HI Peter I think you do need to save table. If you look at the file sizes before you save it, any data written while fastedit is on is not reflected in file sizes. I think the save might right the HEX 1A at the true ends of DAT,MAP and ID files. Also there is a temp DTA file present until you do the save. Regards Bob In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes >Hi Tim, > >When you set fastedit on, the only reason I can think of why MapInfo >enables the Save Table button, is to disable >the FastEdit again. > >When you save the table the FastEdit mode is turned off. Actually there is >no edit to be saved because they have >allready been saved to the table, this is what the FastEdit mode enables. > >So when you push the Save Table and "save" the table with the FastEdit mode >turned on, the only thing that actually >happens is that the FastEdit Mode is turned off for this table. Closing the >table without "saving" it doesn't result in lost >data, because the changes have allready be made in the table. > >I'm not quite sure whether this does explaine the behaviour fully, but it >might give you a better understanding of the >FastEdit mode. > >Peter > > >Peter Horsbøll Møller, GIS Udviklingskonsulent / GIS-Developer >Kampsax A/S - GIS Software & Solutions >Rugaardsvej 55, 5000 Odense, DK >tel: +45 6313 5013, dir:+45 6313 5008, fax: +45 6313 5090 >mailto:[EMAIL PROTECTED] >www.kampsax-gis.dk and www.kampsax.dk >Authorized MapInfo Partner & Distributor in Denmark and Norway. > > >Se mere om Dansk MapInfo Brugerkonference på http://www.kampsax- >gis.dk/Default.asp?ID=296 > >Klik ind på http://www.kortal.dk og se det hele lidt fra oven! >Check http://www.kortal.dk and have a look at Denmark from above! >- Videresendt af Peter Møller/Kampsax - 31-07-2002 15:53 - > > >"Tim.Nuteson" > >[EMAIL PROTECTED] >arget.com>cc: > > Vedr.: MI-L MB: Fastedit on? > >30-07-2002 > >17:57 > > > > > > > > >I have "Fastedit On" set for a table, yet as soon as edits are made the >Save >button on the toolbar lights up. When I click on the Save button, the >FastEdited table is listed as one that needs saving. If I instead just >close the table WITHOUT saving it, I am not prompted to save it. > >1. If Fastedit is ON, why does MI Pro think the table has unsaved edits >(i.e. the Save button lights)? >2. If the Save button is lit, why am I allowed to close the table without >being prompted to save it? > >Can anyone explain this? Using MI Pro 6.5. > >Thanks > >Tim Nuteson >Target Corporation > > > > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 2282 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2348
Re: MI-L Indexing query
Dear Bill I am not aware of there being a maximum. In terms of an optimum the less fields you index on the quicker an index will be updated. However your application might gain enormously by having more indexes so it is difficult to talk of an optimum. In general our experience is that adding one record at a time this is not an issue. However if you are adding a lot at a time and no other users need access while you are doing this, then it is worth dropping the indexes, adding the records, then creating the indexes as a seperate operation. Also keep the index as short as possible. MapInfo will index on the first 127 bytes of a field. If you do not need this length it could be worth maintaining a seperate shorter field in your database, and index on this. It takes less than half the time to reindex a field that is half the length. The same advantage applies when retrieving a record from the index. Try and store numeric values in smallint,integer or float as these indexes will be shorter than a decimal one. If there is a maximum then it is certainly a lot greater than 3 and we have not yet hit it. Regards Bob mapsbydesign.co.uk In message <[EMAIL PROTECTED]>, Data Directions <[EMAIL PROTECTED]> writes > >I have searched the MapInfo manuals and knowledge base but cannot find an >answer to the following: > >Is there an optimal (or maximum) number of indexes that can be applied to >columns within a MapInfo table before their use is ineffective. > >I seem to recall a maximum of three indexes per table, but may be mistaken. > >If someone knows, could they please advise, along with the rationale for (or >if necessary, formula to calculate) the answer. > >Many thanks, > >Bill > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 2676 -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2679
Re: MI-L binary encoding with MB
HI Karl If you are doing any serious number crunching you are best to code up the bulk of the work in a C, C++ or Pascal DLL. Interface with this every second or so from MapBasic. This allows the interface to be MapBasic but gives you machine code speed. Just a do wile loop in MapBasic with no code in it is painfully slow in comparison to say C. You then have a wealth of formats to deal with byte, short, long and double. Good luck, Bob In message <[EMAIL PROTECTED]>, Karl Kliparchuk <[EMAIL PROTECTED]> writes >I don't have an answer for this, but one of my requests to MapInfo Corp >is to produce a MapInfo --> Flash converter so maybe this may show up in >a future version of Mapnfo Pro. > >Karl > > >Karl Kliparchuk, M.Sc. >McElhanney Consulting Services Ltd. >L100 - 780 Beatty Street450 - 999 8th Ave >SW >Vancouver, BC Canada Calgary, AB Canada >V6B 2M1 T2R 1J5 >Tel (604) 683-8521 Tel (403) >262-5042 >Email: [EMAIL PROTECTED] > >>>> Eric Mauvire <[EMAIL PROTECTED]> 08/26/02 02:03PM >>> >Hi, > >I have been working on a way to create binary files with Mapbasic. >My purpose is to convert Mapinfo maps into swf (Flash) files. >It works, but it needs a classical conversion from base 10 to base 2 >for >integers. >Actually, as usual, Mapbasic appears very slow when it's highly >sollicitated. > >Does anyone knows any fonction in the Win API that does that simple >encoding job. >I would like to call this function as a dll from within MB. > >Thnaks by advance, > >Eric Mauvire >EMC3 www.emc3.fr <http://www.emc3.fr/> >214 B Ch des Izards 31140 Launaguet >tel 06 08 99 95 02 - 05 34 40 84 66 >fax : 06 73 270 779 > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 2672 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2682
MI-L MasterMap to MapInfo - free seminars Windsor/Southampton UK
Dear List The following free seminars might be of interest to potential users of Ordnance Survey data with MapInfo products. It may also be of interest to MapInfo users who would like to learn more about GML (Geographic Markup Language). We are running a series of seminars with MapInfo and Ordnance Survey discussing the use of MasterMap data with the MapInfo range of software. The first two seminars are:- Thursday 12th September - MapInfo UK offices Windsor Monday 14th October - Ordnance Survey offices, Southampton Issues to be looked at include:- Migration from NTF products to MasterMap The pros and cons of mapping "history" Future layers in MasterMap Problems encountered to date Solutions for problems to date eGovernment web mapping and MasterMap Two alternative translators will be shown both of which run inside MapInfo. MapGML is a very fast solution for customers who take full resupply each time, and GML Manager is designed for customers who require history and decide to take MasterMap "update only" regularly. The seminars are free and customers are welcome to send more than one delegate. However it is important that you regiser with us first to reserve a place as places are limited. In addition this will allow us to organise lunch and refreshments. The seminars will start at 10:00 ( coffee from 9:30 ) and will finish at 15:30. Lunch and refreshments will be provided. We will also be holding two further seminars, as per above agenda, in late October at Warrington and at Doncaster. CDR will join us at these meetings to talk about Data Capture. Please contact us as below to reserve a place. email [EMAIL PROTECTED] tel 01633 881117 fax 01874 610677 Bob Young By Design MapInfo Premier Partner -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2862
Re: MI-L delete characters within a string
Hi Renee You need to look at two fuctions:- left$(string,n) right$(string,n) In your specific example you need left$(example,4) + right$(example,4) ie take four leftmost characters and concatenate rightmost four characters ( but see note about trim functions below). However your positions of the minus signs might vary. If this is the case also read up on Instr(n,string,substring) This would allow you to find out the positions of the "-" eg lnPos = Instr(1,example,"-") This would return 5 for your example. mid$(string,nStart,nLength) would also be worth reading up. With mid$ and Instr you should be able to strip any string to exactly what you want. Also read up on ltrim$(string) and rtrim$(string). These will allow you to remove leading and trailing ( respectively ) spaces from the string. All of the above functions are standard Basic functions and would be in virtually all dialects of basic. In Visual Basic you have the options to drop the $ but the functionality is exactly the same. Regards Bob By Design www.mapsbydesign.co.uk In message <0A005268C8DED311A23E0008C75D1EFF095D7BCE@sj- exchange.ci.sj.ca.us>, Gerasimtchouk, Renee <[EMAIL PROTECTED] a.us> writes >Hi all, >I'm looking for mapbasic syntax to delete two middle numbers within a string >of numbers. >Ex. RA00-12-002 >and I want to delete the -12 so the result would be >RA00-002 > >TIA > > > >- >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >Message number: 2860 > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2866
Re: MI-L MapInfo file size limit
Hi Vinny The ID file contains a list of 4 byte pointers into the MAP file thus allowing record n to find map object n. a 4 byte long will store +- 2GB and MapInfo have used a signed long thus limiting themselves to half of this. Therefore even on systems(eg Win2000) which allow files to be the size of the drive the addressing in the ID and MAP file limit the MAP file size to 2GB. I have asked senior staff at the MapInfo European Conference in Cannes this year if there are any plans to move to larger files and they certainly have not ruled it out. There is obviously strong support for Oracle 9i but many of the techies would like to improve the existing TAB format. I disagree totally with Doug that at 2 GB the MAP file gives bad performance. Quite the reverse. If you compare it with ArcView SHP file format with small coverages you will not see much difference between MAP and SHP. The larger the coverage the more dramatic the improvements Mapinfo R tree gives you compared to SHP. MapInfo reads fixed size index blocks of data from the drive to find map features. For just one extra block read it can read a file 25 times bigger. Lets say a depth of 4 reads gives you access to 1 MB then 5 reads will give you access to 25 MB and 6 reads gives access to 625 MB. This is probably the greatest feature of MapInfo - that it does handle very large MAP files exceptionally well. I personally believe MapInfo should re engineer their excellent format to make use of int64 ( 8 byte pointers ) on Win 2000 and beyond. Having said that I am surprised that the 2 GB limit concerns you at Leicestershire. If your Mastermap data is split into layers you should not be anywhere near this. The only time the 2 GB limit should be an issue is with coverages much larger than 1 County. eg Wales, Scotland or National Coverage. If you want to try one of our approaches to MasterMap translation into MapInfo native format you are welcome to a free evaluation. The answer to National Coverage is the use of seamless layers. In a way a seamless layer is the extension of the RTree index. First MapInfo finds the MBRs of the base tables that intersect the screen. For this it gets the benefits of the R Tree in the seamless layer. Then only for the base tables that intersect the screen it uses the bases tables R Trees to narrow its search to a small part of each base table. Hence performance is still very acceptable. The drawback of seamless tables is you lose the use of data indexes ( the IND files ) and you lose the ability to thematically map. Also if on a server network traffic will be higher as one R Tree index over the top of another R Tree index is not as efficient as if it was all in one - ie if they did introduce int 64 there would be less reads to get to the same data. If your limit is within the DAT file rather than the MAP file you should really be using relational joins on the GML tags. It is pointless holding long strings over and over again in a flat file when the same result can be achieved by the use of relational tables. The DAT files can be reduced to a size much smaller than the MAP files. Your limit should come from the MAP files and if you split these sensibly the largest needed for Leicestershire would be well under 1 GB never mind 2 GB. MapInfo is a full RDBMS. MapInfo is more than a match for MasterMap data but it now warrants using the full power of an RDBMS whereas with NTF data we easily got away with flat files as Landline was really just graphic data not full GIS data. Hope this helps in resolving your file size problems. Feel free to ring me if I can be of any help. I apologise to non UK listers who may think the above is irrelevant for them. However I do believe as GML becomes more pervasive and data attribution increases the question will become more relevant in other countries. Regards Bob (0044) 1633 881117 www.mapsbydesign.co.uk In message <397693EFEA62D411806E00B0D04972310134F7C2@LCCNTEX3>, Vinesh Govind <[EMAIL PROTECTED]> writes >Users > >I consider myself to be an intermediate user of MapInfo software so bear >with me if my query is too simplistic for some of the MapInfo gurus. > >I've been doing some translation of OS MasterMap data and have been told >that the maximum file size limit for a MapInfo table is 2GB. >Is this correct?..Why? >If this is indeed a correct assumption, then are there any plans for the >future by MapInfo Corp. to increase the file size limit. > >Thanks. > >Vinny > > >___ >The contents of this message do not necessarily represent the >opinions, views, policy or procedures of Leicestershire County Council. > -- bob young - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 3169
Re: MI-L MapInfo file size limit
Hi Vinny Thanks for the reply. However if the data is stored relationally this will not be a problem. The updates include "departed features" as well as new features. If your data is split into current holding ( ie whats on the ground now ) and history ( ie previous versions ) then the current holding can only increase for the following reasons. The OS continue to refine the land usage. eg a 1 hectare field that is described as one parcel in terms of geometry but data describes it as containing coniferous and rock is sub divided into 3 0.3 hectare polygons with more specific attribution. The solution to above is more MapInfo tables to hold the output. ie the 1 acre field would be on one layer. The three subdivisions could be on three layers for natural, rock and coniferous land types. The increase in people living alone and the inevitable development of green field sites leads to more toids ( ie geometric features). This problem will mean a creep towards the 2 GB limit. However if you are currently around the 400GB per table that leaves a massive amount of loss of countryside before you need worry about the 2 GB limit! Also the largest theme is natural land. The building layer has more spare capacity at present. Building development will not increase what at present is the largest layer. ( I doubt if it will reduce it either - although area will reduce the coordinates will probably not ). I think the main thing to remember is that change only should settle down to about 2 to 3 % change per year ( a figure I have had from OS ). Much of this will replace what is there rather than be additional data. The Positional Accuracy Improvement program in certain areas will lead to large volumes of change but should not increase your files sizes. One set of geometry will be replaced with a more accurate set of geometry but virtually the same number of coordinates. Although it is safe ( and advisable ) to remove attribution from your published maps try and make sure your model stores full attribution somewhere. Although you at present might think certain attribution is not needed, future users might feel differently! If you are applying update only and your model only carries forward reduced attribution this might be a problem. I would recommend with "change only update" using a local holding storing full attribution from which reduced attribution layers for MapInfo can be derived for your current end users. This approach gives you the best of both worlds. Regards Bob In message <397693EFEA62D411806E00B0D04972310134F7C5@LCCNTEX3>, Vinesh Govind <[EMAIL PROTECTED]> writes > >Bob > >Thanks very much for the informative reply. > >I should say from the outset that we have not yet reached the 2GB >file size limit and more importantly our file sizes should >gradually diminish as we remove some of the atrribute data that is >not of any relevance to us. > >However, my concern is that as one receives "updates" to MasterMap, >file sizes will gradually grow and the 2GB limit could get >precariously close. If this is the case, then a further concern I >have is that companies are selling translators for MasterMap but >are not warning users of a future potential problem that could >arise. > >My apologies to non UK listers who find this topic irrelevant. > >Thanks. > >Vinny > >-Original Message- >From: bob young [mailto:[EMAIL PROTECTED]] >Sent: 20 September 2002 14:27 >To: Vinesh Govind >Cc: MapInfo Lists (E-mail) >Subject: Re: MI-L MapInfo file size limit > > >Hi Vinny > >The ID file contains a list of 4 byte pointers into the MAP file >thus >allowing record n to find map object n. > >a 4 byte long will store +- 2GB and MapInfo have used a signed long >thus >limiting themselves to half of this. Therefore even on systems(eg >Win2000) which allow files to be the size of the drive the >addressing >in the ID and MAP file limit the MAP file size to 2GB. > >I have asked senior staff at the MapInfo European Conference in >Cannes >this year if there are any plans to move to larger files and they >certainly have not ruled it out. There is obviously strong support >for >Oracle 9i but many of the techies would like to improve the >existing TAB >format. > >I disagree totally with Doug that at 2 GB the MAP file gives bad >performance. Quite the reverse. If you compare it with ArcView SHP >file >format with small coverages you will not see much difference >between MAP >and SHP. The larger the coverage the more dramatic the improvements >Mapinfo R tree gives you compared to S
Re: MI-L MapInfo file size limit
Hello Doug I am sorry if you were upset by my reply. The move to MasterMap includes a rich set of attribute data - but a large number of users ( the majority ) will still primarily be interested in using the maps for a reference to position their own layers. The rich attribution will help to split the objects over multiple layers and to set the style of the objects. In such cases "drawing the stuff" is the essence of their proposed usage along with usage of the info tool. Vinnys original question related to the size limit problem and in particular with regard to MasterMap. I have pointed out that the DAT file does not need to be big, and thus the 2GB limit should affect the MAP file first. If you think that a high percentage of users will make SQL queries against non spatial data in the current topological layers and then further NOT want to view them then we also disagree on another point! You suggest my answer was misleading - again I disagree. As a MapInfo (only) Partner I am much more concerned by your misleading comments quoted below:- "You do need to be wary of creating the large MI files - they become extremely un-user friendly! eg. slow drawing " I think it is you misleading the list - it is not slow drawing - it is a superb graphics format and only now is Oracle 9i coming close for speed of drawing. Therefore your suggestion that users need to move to SQL Server or Oracle to work with MasterMap is again misleading the list. The MapInfo native format is more than up to the task - where the area covered is County or smaller. With all due respect I did cover both points ie DAT and MAP. With regard to MAP you now seem to be backing off and agree that drawing the graphics with MapInfo is not a problem. With regard to the DAT file you have misunderstood me. I pointed out that the DAT should be held relationally instead of in a flat file. Vinny is storing strings such as "rock;scrub;coniferous tree" in a single field and as you now say running SQL queries on this would be a nightmare. You would really need to use an Instr() type call and pass a lot of data from server to client. However if the data is stored relationally the DAT files can be very small - thus moving the file size problem to the MAP file ( graphics) and not the DAT file. I think with MasterMap data stored boils down to what sort of SQL query the users will want to make (IF ANY!) and what they need to retrieve through the info tool. One option we include is to turn the string round to be the field name so that the field content becomes true or false. For example instead of storing field MAKE to be "Manmade" store a field MANMADE to be TRUE or FALSE. This is a single byte, instead of a string of say 20 bytes. Also an SQL query on this would be much faster and a thematic on such field values would be possible but impossible within the concatenation Vinny is using. NOt all users will want to know the same attributes and the published layers would ideally be tailored to end users needs. As mentioned above, I think it very unlikely that many users will run SQL queries on data attributes in MasterMap. By colouring objects appropriately from data attributes you effectively have a thematic map removing many users need for data attributes. The most likely use of the GML tags will be with the info tool - for example the new addresspoint theme gives the address. The info tool will give us the house number etc. Not many people will want to select all houses where the house number = "71" for example but they will want to use info on the data. I have posted this reply back to the list as you put yours there and I think the list should be aware of the strengths of the product the list is focused on. The original question was to do with file size limit and several us have now answered that in detail. I would suggest if you want to discuss this in any greater detail we take it off line as our personal differences as to the relative merits of MapInfo/ESRI are not relevant to this list. Regards Bob In message <[EMAIL PROTECTED]>, GIS Coordinated <[EMAIL PROTECTED]> writes >Bob >try your sql queries on a 2gig dat file - its just half the story to draw >the stuff! (often users dont even need/or want to draw anything - just >query). This was my real general point. Users out there reading this list >will think they can just throw everything in a huge pile and expect great >performance as you suggest below (which is ok for drawing) but you should >always consider what exactly you want to do with the data, and then >carefully determine the best way to store it. > >regards > > >Doug > > >-Original Message- >From: bob young [mailto:[EMAIL PROTECTED]] >Sent: 20 September 2002 16:13 >To: Vinesh Govind >Cc: MapInfo Lists (E-mail) >Subject: Re: MI-L MapInfo file size limit > > >Hi Vinny > >Than
MI-L MID/MIF Production
Hi Listers Does anybody know of a way to produce MID/MIF from a MapInfo table without having a copy of MapInfo, preferably thats free? Regards Bob Young Maps By Design -- Bob Young ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
[MI-L] Clash using Find with WinChangedHandler
Hi List Can anyone please shed any light on the difference between setting the map centre with use of Find, and setting the map centre with Change View? Specifically I am using WinChangedHandler to build a MapInfo table "on the fly". I am writing a MapInfo table "on the fly" from a large dataset. The MapInfo table contains just the contents of the screen. The routine works ok for pan and zoom.It also works if the screen centre, or zoom width are changed with Change View. However when I use the Find command I get a crash. The Microsoft error signature points to ntdll.dll. During the WinChangedHandler I am overwriting a table that is in the Map Window - which almost certainly is at the root of the problem. However within the routine I am using Set Handler WinchangedHandler off and Set Event Processing off and at the end turn both back on. Therefore the map should not redraw until the end of the routine by which time the "new" table is ready. Also as previously stated the routine works with zoom, pan and even ChangeView. So could anybody suggest what is different when using Find? Lost two days already on this !!! Regards Bob @www.MapsByDesign.co.uk -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
[MI-L] Find/WinchangedHandler - version inconsistency
Hi List With regard to my posting about an hour ago, I can now report that the code that crashes in MapInfo 6.5 works in Version 8.0! Just as a reminder even in 6.5, it only crashes using Find to set centre. Zoom, Pan and Change View all work ok. However Version 8.0 is not without its own "features". In 6.5 the working methods just redraw the map. In version 8.0 I need a print(in WinChangedHandler) to the message window to get the map to appear! If I do not add a print ( just print "." is enough ) then I need to do a Window redraw. So why does MapInfo 6.5 crash on Find, and yet 8.0 ok? and Why does version 8.0 need a print statement, whereas 6.5 does not? Trying to cater for these differences between versions of MapInfo is really frustrating! Regards Bob @www.MapsByDesign.co.uk -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Clash using Find with WinChangedHandler
Hi Greg I didn't explain in enough detail. The table I am using for the search is not one of the tables get overwritten. I am actually using a town gazetteer to search anywhere in the country. Then when the position is found I am generating MapInfo tables from MasterMap on the fly. The code works really well now on Version 8.0. It will draw a 1000 metre wide map in less than a second anywhere within the country. The crazy thing is I need a print statement at the end of the WinChangedHandler, otherwise I need to do a screen redraw. If I put the screen redraw in place of the print it does not work. The same code crashes MapInfo 6.5. I am going to ask a separate question regarding support of Oracle. What I am trying to do is similar so the version support for this came in is probably significant. Regards Bob In message <[EMAIL PROTECTED] .police.pri>, Driver, Greg 9434 <[EMAIL PROTECTED]> writes > >Bob, > >This may be stating the obvious but the Find statement searches a >mappable table and the change view/zoom/pan all work on map >windows. So, if you're searching a table that you're over-writing >won't that get MapInfo's knickers in a twist? But if you just >moving the map window using pan/zoom etc, then it'll be able to >cope with this? > >Just a thought. > >Greg Driver > >System Administrator >Applications Support > ICT >NOT PROTECTIVELY MARKED > > >-Original Message- >From: bob young [mailto:[EMAIL PROTECTED] >Sent: 14 December 2005 20:13 >To: MapInfo-L@lists.directionsmag.com >Subject: [MI-L] Clash using Find with WinChangedHandler > > >Hi List > >Can anyone please shed any light on the difference between setting >the map centre with use of Find, and setting the map centre with >Change View? > >Specifically I am using WinChangedHandler to build a MapInfo table >"on the fly". I am writing a MapInfo table "on the fly" from a >large dataset. The MapInfo table contains just the contents of the >screen. The routine works ok for pan and zoom.It also works if the >screen centre, or zoom width are changed with Change View. > >However when I use the Find command I get a crash. The Microsoft >error signature points to ntdll.dll. > >During the WinChangedHandler I am overwriting a table that is in >the Map Window - which almost certainly is at the root of the >problem. However within the routine I am using > > Set Handler WinchangedHandler off >and > Set Event Processing off > >and at the end turn both back on. > >Therefore the map should not redraw until the end of the routine by >which time the "new" table is ready. Also as previously stated the >routine works with zoom, pan and even ChangeView. > >So could anybody suggest what is different when using Find? > >Lost two days already on this !!! > >Regards > > >Bob >@www.MapsByDesign.co.uk > > > >-- >bob young > -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
[MI-L] MapInfo version support for Oracle
Dear List This posting links to a question asked yesterday regarding WinChangedHandler. I am writing code that will "on the fly" extract an "area of interest" from a very large data holding (58 GB). The code now works really well in Version 8.0 of MapInfo. However the same code makes version 6.5 of MapInfo crash. My concern is will the code work in future versions of MapInfo. The process I have written must be very similar to how MapInfo "draws" from Oracle spatial. I use the WinChangedHandler to call a C DLL that rewrites any tables that appear in the current map window. On exit from the WinchangedHandler the new layers exist .Time taken is under 1 second for a 1 km width. At 500 metre map width, its too quick to time. What appears to happen is that MapInfo 6.5 carries on "checking" for existance of tables. So if the WinChangedHandler overwrites the table it crashes. Actually it only crashes if the FIND is used to recentre the map ( search done from table NOT being overwritten ). Even in 6.5 all other map movement - ie zoom, pan and change view work ok. In version 8.0 all methods work, but I do need a print statement at the end of the WinchangedHandler. Its as if this print allows MapInfo to "catch up" with itself. If the print is not there, then the map window stays blank. A redraw puts it right. If I put the redraw in place of the print, it does not work. Has anybody reading this posting done anything similar. I am so close to a final solution, but I cannot leave it printing a line into the message window. Also, without understanding the difference between 6.5 and version 8.0, I am worried about support going forward. Regards Bob Young @MapsByDesign.co.uk -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Need GPS Unit to produce Snail Trail that ccan be added to Existing MI Pro Street Layer
Hi Doug You can do this with Maps4Site. The maximum sampling rate is 1 point per second - this is user configurable. You would only need the Lite version. You would need any Pocket PC/GPS combination. QTek and HP now both have released Pocket PC with the GPS built in. Maps4Site can view existing MapInfo tables in WGS84, so you will be able to follow yourself on any maps you have in MapInfo format. When you have finished collecting your "trail" you can export the data as MID/MIF and import it into MapInfo. There is an evaluation version at www.Maps4Site.co.uk, so you can test for free. If you need to test for longer than the standard timeout, let me know and I'll send you a password. Its quite a small program, and needs no install - just run the EXE off the SD or CF card. Regards Bob @www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Doug Wassmer <[EMAIL PROTECTED]> writes >Hi List: > > > >Here is my challenge. I need up-to-date, accurate street layers. >Affordable Aerial Photos are always behind the growth curve, and >commercially produced street layers have the same problem and often show >non-existent roads > > > >I would like to be able to throw an inexpensive GPS unit on the seat of a >truck and drive slowly thru new neighborhoods and record my route, adding a >lat/lon point to a continuously recorded snail trail at a recording rate of >at least 1point/second. Slow update rates likely will result in missed >corners and chords instead of smooth arcs representing the curves in the >roads. > > > >Once the neighborhood is driven, I would like to be able to download the >data and produce a MapInfo TAB file, either from a Shape File download or a >comma delimited ascii data download. > > > >Can anyone recommend moderately priced GPS unit that will allow me to do >this. I know that there are sophisticated Avionics units that will do this, >but they are out of by budget range. > > > >Thanks > > > >Doug Wassmer > >[EMAIL PROTECTED] > >___________ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Fixes and New MapInfo Features
of the smart street labeling that's in MapText's Label-EZ? >> Why >> not provide line styles where you can change both the inside AND >> outside >> color? Why not color gradational fills? How about vector layer >> translucense? How about finishing the cartographic legend utility? > >Mit freundlichem Gruss / Best Regards >Flavio Hendry > > >TYDAC NEWS http://www.tydac.ch/german/index.php?menu=News_actual > > Mit freundlichen Gruessen / Kind Regards > mailto:[EMAIL PROTECTED] > TYDAC AG - http://www.tydac.ch > Geographic Information Solutions > Luternauweg 12 -- CH-3006 Bern >#### Tel +41 (0)31 368 0180 - Fax +41 (0)31 368 1860 > > > >___ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l > >-- > >Checked by AVG Free Edition. >Version: 7.1.371 / Virus Database: 267.14.3/209 - Release Date: 12/21/2005 > > -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] labels & formatdate$()
Hi Mike Its a quick response, not thought through properly but why accept null dates in your database? Could you allow a "formatable" date like Microsoft's 1/1/80 to mean "null" . Then update your databases "once and for all" to these values. Any programs adding data would need to enforce this rule, but at least your labelling would work? Its not answering your question I know but hopefully its a potential solution. An alternative :- You could do a select on your table to split data into valid dates and non valid dates. You could map both layers but just label valid date layer. Regards Bob MapsByDesign.co.uk <[EMAIL PROTECTED]> writes >We have databases were we record start and ending dates. I need to be able to >query records and have the dates in the label. I have found that null values >in >these date fields are troublesome. > >For example: If I use the formatdate$(abddate) to display the date in a format >that is easy to read and abddate=null; I get an error message instead of a >label. > >So I tried to make different layers-one non-null & one null. I couldn't quite >get it right, there always seemed to be records "fall through the cracks". >(there isn't a isnull() function) > >I have looked for a solution and haven't found much. At this point, I believe >that I'm going to have to query the data into different layers (if I want to >use >the formatdate$() function). > >How do I separate the null date values from non-null date values? >Can you put a conditional statement in a label expression? > >thanks. > >_______ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
[MI-L] 2 GB limit increased to 16 Terrabytes
Dear List I am pleased to report that By Design have defined and built a spatial file format that can be viewed from within MapInfo and can have files up to 16 Terrabytes in size. We have used the R-tree structure defined by Guttman in 1984 and implemented support for text, points, lines and regions at the leaf nodes. All internal pointers use 64 bit long integers hence the new file size. It therefore offers similar performance to native TAB but is not limited to 2 GB file sizes. Our first implementation for this format is for MasterMap of Great Britain. We have produced a free translator to load GZ ( compressed GML ) directly into the new format. The free translator runs inside MapInfo Professional. This process is very quick. It loads over 12000 objects per second. National Cover of GB which is about 700 GB of GML ( and 33 GB of GZ ) loads in under nine hours ( and produces 60 GB of data ). We have produced an MBX called MIMIC that converts the new 64 bit format to native TAB on the fly, so a MapInfo Professional user can pan and zoom on these huge layers just the same as with native TAB. These layers can be mixed and matched with native TAB, Oracle spatial and WMS/WFS layers with MapInfo Professional. If users in any other Countries are using GML and are interested in this we would very much like to modify the free translator to work with other GML datasets. There are details and free downloads at www.GBplc.co.uk Regards Bob www.MapsByDesign.co.uk -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] 2 GB limit increased to 16 Terrabytes
Hi Lars The first version of the MBX was released now because of a separate issue. The new Ordnance Survey data is in GML format whereas it used to be in a format called NTF. NTF will be withdrawn, so what I have also put in the MIMIC mbx is the ability to create Landline NTF files from our 64 bit format and therefore from MasterMap GML. I appreciate this might not seem relevant, but it is why I released the viewer early. The first version only builds an AOI ( area of interest ) for one map window. I have started coding for multiple windows. A table that is open in more than one window, needs an AOI for each map window. The fact that this data is built "on the fly" will allow for some interesting transforms. For example labelling on a curve is a possibility because MIMIC decides what MapInfo gets to see in its native tables! I plan to include rotation of raster and rotation of vector in a future version. With regard to your second question its not there, but its certainly a possibility. The great thing about defining a format is you can add what you like! For example a key feature of MasterMap is change only updates. Ordnance Survey can issue customers with change only data rather than full supply.It has been possible to build in features to the format that make this process very quick. I would be very interested to hear your ideas on password protection. Do you mean a password to open up through MapInfo Professional, or full encryption so that a "dos debug" user would not see text strings? With regard to sample datasets, at present it only works with GML as used by MasterMap! If there is sufficient interest in this I could write a TAB to GML(GZ) convertor and then people could try it out with their own data. Thanks for the support! Regards Bob In message <[EMAIL PROTECTED]>, Lars V. Nielsen (GisPro) <[EMAIL PROTECTED]> writes >Cheers Bob ! > >Bob, this sounds like the biggest improvement to MIPro in the last >4-5 years. Expect to be purchased by MapInfo Corp. right away ;-D > >I do have a two fast questions for you: >1. Does the mbx support multiple map window ? >2. Does the file format support password protection of data ? > >And, are there sample datasets available for testing ? > >Best regards / Med venlig hilsen >Lars Nielsen >GisPro > > >bob young wrote: >> Dear List > >> I am pleased to report that By Design have defined and built a >> spatial >> file format that can be viewed from within MapInfo and can have >> files up >> to 16 Terrabytes in size. > >> We have used the R-tree structure defined by Guttman in 1984 and >> implemented support for text, points, lines and regions at the >> leaf >> nodes. All internal pointers use 64 bit long integers hence the >> new file >> size. It therefore offers similar performance to native TAB but >> is not >> limited to 2 GB file sizes. > >> Our first implementation for this format is for MasterMap of >> Great >> Britain. We have produced a free translator to load GZ ( >> compressed GML >> ) directly into the new format. The free translator runs inside >> MapInfo >> Professional. This process is very quick. It loads over 12000 >> objects >> per second. National Cover of GB which is about 700 GB of GML ( >> and 33 >> GB of GZ ) loads in under nine hours ( and produces 60 GB of >> data ). > >> We have produced an MBX called MIMIC that converts the new 64 >> bit format >> to native TAB on the fly, so a MapInfo Professional user can pan >> and >> zoom on these huge layers just the same as with native TAB. >> These layers >> can be mixed and matched with native TAB, Oracle spatial and >> WMS/WFS >> layers with MapInfo Professional. > >> If users in any other Countries are using GML and are interested >> in this >> we would very much like to modify the free translator to work >> with other >> GML datasets. > >> There are details and free downloads at www.GBplc.co.uk > > > >> Regards > > >> Bob >> www.MapsByDesign.co.uk > > >> -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] 2 GB limit increased to 16 Terrabytes
>I assume from this description that this is a format for vector data, with >the same object types that MapInfo Professional (and bedmates) uses? > That's correct. This new format holds the same object types as MapInfo and implements a similar RTREE spatial index - the main difference is the use of 64 bit long integers as pointers instead of 32 bit integers. On an NTFS file system this then allows files up to 16 Terrabytes, and on older FAT32 systems up to 4 GB. > >And that those geometric objects are completely described by the GML >standard? > The GML data files defines the type of object, gives it's full geometry and also full data attribution. However GML as used in MasterMap does not define its appearance. Its up to the user to decide this. So our free translator uses a "user definable" style file. For example this might say that a building outline should be Point Size 2.5 and blue, and that the "fill" for the building is style 45, and grey. Regards Bob In message <[EMAIL PROTECTED]>, SCISOFT <[EMAIL PROTECTED]> writes >I assume from this description that this is a format for vector data, with >the same object types that MapInfo Professional (and bedmates) uses? > >And that those geometric objects are completely described by the GML >standard? > >IL Thomas >GeoSciSoft - Perth, Australia > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:mapinfo-l- >> [EMAIL PROTECTED] On Behalf Of bob young >> Sent: Wednesday, January 11, 2006 6:33 PM >> To: MapInfo-L@lists.directionsmag.com >> Subject: [MI-L] 2 GB limit increased to 16 Terrabytes >> >> Dear List >> >> I am pleased to report that By Design have defined and built a spatial >> file format that can be viewed from within MapInfo and can have files up >> to 16 Terrabytes in size. >> >> We have used the R-tree structure defined by Guttman in 1984 and >> implemented support for text, points, lines and regions at the leaf >> nodes. All internal pointers use 64 bit long integers hence the new file >> size. It therefore offers similar performance to native TAB but is not >> limited to 2 GB file sizes. >> >> Our first implementation for this format is for MasterMap of Great >> Britain. We have produced a free translator to load GZ ( compressed GML >> ) directly into the new format. The free translator runs inside MapInfo >> Professional. This process is very quick. It loads over 12000 objects >> per second. National Cover of GB which is about 700 GB of GML ( and 33 >> GB of GZ ) loads in under nine hours ( and produces 60 GB of data ). >> >> We have produced an MBX called MIMIC that converts the new 64 bit format >> to native TAB on the fly, so a MapInfo Professional user can pan and >> zoom on these huge layers just the same as with native TAB. These layers >> can be mixed and matched with native TAB, Oracle spatial and WMS/WFS >> layers with MapInfo Professional. >> >> If users in any other Countries are using GML and are interested in this >> we would very much like to modify the free translator to work with other >> GML datasets. >> >> There are details and free downloads at www.GBplc.co.uk >> >> >> >> Regards >> >> >> Bob >> www.MapsByDesign.co.uk >> >> >> -- >> bob young >> ___ >> MapInfo-L mailing list >> MapInfo-L@lists.directionsmag.com >> http://www.directionsmag.com/mailman/listinfo/mapinfo-l >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.1.371 / Virus Database: 267.14.17/226 - Release Date: >> 10/01/2006 > >___ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] 2 GB limit increased to 16 Terrabytes
I'm thinking about writing a free TAB to GML translator following the interest yesterday. If I do I'll send you a copy so you can see the structures. It's very verbose but ZIPS up nicely , and I could write it straight to the GZ format to keep it nice and fast! Regards Bob In message <[EMAIL PROTECTED]>, SCISOFT <[EMAIL PROTECTED]> writes >Bob > >Sounds good. > >Extensions to other flavours of GML would be nice. > >I wonder if I can encourage Manifold people to do the same? As you probably >know, they bundle all objects into a single .MAP file, though external >rasters and RDMS databases can be easily tied into that "project" file. > >Manifold needs a good interchange format. At present, it seems that the >MIF/MID is the best available (TAB is also supported, sort of OK). > >They support MIF/MID quite well, though MapInfo's .WOR files are a real >problem. That's why Stephen Chan's "Hard Coded Thematics" MBX >(http://www.directionsmag.com/files/index.php/view/675 ) is quite useful, as >a data preparation for Manifold. > >IL Thomas >GeoSciSoft - Perth, Australia > > >>I assume from this description that this is a format for vector data, with >>the same object types that MapInfo Professional (and bedmates) uses? >> >> > That's correct. This new format holds the same object types as MapInfo >> > and implements a similar RTREE spatial index - the main difference is >> > the use of 64 bit long integers as pointers instead of 32 bit integers. >> > On an NTFS file system this then allows files up to 16 Terrabytes, and >> > on older FAT32 systems up to 4 GB. >> > >> >> >And that those geometric objects are completely described by the GML >> >standard? >> > >> The GML data files defines the type of object, gives it's full geometry >> and also full data attribution. However GML as used in MasterMap does >> not define its appearance. Its up to the user to decide this. So our >> free translator uses a "user definable" style file. For example this >> might say that a building outline should be Point Size 2.5 and blue, and >> that the "fill" for the building is style 45, and grey. >> >> Regards >> >> Bob -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
[MI-L] Exporting GML and GZ
That sounds interesting. However GML is part of OGC standards, this is one of the reasons it was chosen by Ordnance Survey. It sounds like XML within ZIP is going to be similar, and I could perhaps do some mods. later after getting GML/GZ cracked. I've not worked with Linux at all. Cheers Bob In message <[EMAIL PROTECTED]>, SCISOFT <[EMAIL PROTECTED]> writes >Dare I suggest you write to the XPS format, when it's finalized / announced? > >That's the Windows Vista Print format (XML within linked ZIP package), for >Word 12 + printing + exchangeable "PDF-replacement" format. > >New printers will be released with special XPS printer drivers. Imagine it >as a better Postscript. > >But you're NOT a Loonix fiend, are you? > >IL Thomas >GeoSciSoft - Perth, Australia > >> -Original Message- >> From: bob young [mailto:[EMAIL PROTECTED] >> Sent: Thursday, January 12, 2006 5:42 PM >> To: [EMAIL PROTECTED] >> Cc: MapInfo-L@lists.directionsmag.com >> Subject: Re: [MI-L] 2 GB limit increased to 16 Terrabytes >> >> >> I'm thinking about writing a free TAB to GML translator following the >> interest yesterday. If I do I'll send you a copy so you can see the >> structures. It's very verbose but ZIPS up nicely , and I could write it >> straight to the GZ format to keep it nice and fast! >> >> Regards >> >> Bob >> >> >> In message <[EMAIL PROTECTED]>, SCISOFT >> <[EMAIL PROTECTED]> writes >> >Bob >> > >> >Sounds good. >> > >> >Extensions to other flavours of GML would be nice. >> > >> >I wonder if I can encourage Manifold people to do the same? As you >> probably >> >know, they bundle all objects into a single .MAP file, though external >> >rasters and RDMS databases can be easily tied into that "project" file. >> > >> >Manifold needs a good interchange format. At present, it seems that the >> >MIF/MID is the best available (TAB is also supported, sort of OK). >> > >> >They support MIF/MID quite well, though MapInfo's .WOR files are a real >> >problem. That's why Stephen Chan's "Hard Coded Thematics" MBX >> >(http://www.directionsmag.com/files/index.php/view/675 ) is quite useful, >> as >> >a data preparation for Manifold. >> > >> >IL Thomas >> >GeoSciSoft - Perth, Australia >> > >> > >> >>I assume from this description that this is a format for vector data, >> with >> >>the same object types that MapInfo Professional (and bedmates) uses? >> >> >> >> > That's correct. This new format holds the same object types as >> MapInfo >> >> > and implements a similar RTREE spatial index - the main difference is >> >> > the use of 64 bit long integers as pointers instead of 32 bit >> integers. >> >> > On an NTFS file system this then allows files up to 16 Terrabytes, >> and >> >> > on older FAT32 systems up to 4 GB. >> >> > >> >> >> >> >And that those geometric objects are completely described by the GML >> >> >standard? >> >> > >> >> The GML data files defines the type of object, gives it's full geometry >> >> and also full data attribution. However GML as used in MasterMap does >> >> not define its appearance. Its up to the user to decide this. So our >> >> free translator uses a "user definable" style file. For example this >> >> might say that a building outline should be Point Size 2.5 and blue, >> and >> >> that the "fill" for the building is style 45, and grey. >> >> >> >> Regards >> >> >> >> Bob >> >> -- >> bob young >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: >> 11/01/2006 > -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: Ang. RE: [MI-L] Number of fields
Hi Mats The 2 GB limit is a MapInfo limit and NOT an OS limit. Even under Fat32 you can have files up to 4 GB and under NTFS you can have files up to 16 Terrabytes. MapInfo is limited in this way because they use a signed 32 bit long as a pointer to the Map File. I have created a new 64 bit file format and have tested this with full National Coverage of Great Britain. We have information on this at: http://www.GBplc.co.uk I have used this on FAT 32 and so can confirm the 4 GB limit. I have also tested up to 12 GB files under NTFS. I would need an even larger data set to go above this. I am working on a TAB to GZ convertor so if anyone has large datasets they would like to test keep an eye on GBplc.co.uk for the new free TAB to GML(compressed to GZ) as well as free GML(compressed to GZ) to BIG ( 64 bit format). Regards Bob @www.MapsByDesign.co.uk In message <[EMAIL PROTECTED] e.se>, Mats Elfström <[EMAIL PROTECTED]> writes >Hi Dave! > >I think your analysis is correct. >I believe the numbers are as follows: > >Max field length: 255 bytes >Max number of fields: 255 (as someone pointed out, if you need that >many, it's bad database design) >Max length of record: ~4000 bytes (quickly reached if you join in some >Access tables) >Max Tab file size: 2 GB (OS limit, not MapInfo) > >I have noted on some occasions that some data tables have very long >character fields, 255 bytes. >I believe this data to be of Access origin, and originally were memo >fields which have no limit length in Access. >As the DB structure of MI cannot handle memo fields they probably get the >max character field length when put into the MI DB format. >Imagine what will happen if you have a number of such fields, the 4000 >byte barrier is reached very quickly. > >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 > > > >"David Baker" <[EMAIL PROTECTED]> >Sänt av: [EMAIL PROTECTED] >2006-01-24 01:06 >Sänd svar till >[EMAIL PROTECTED] > > >Till >mapInfo-L@lists.directionsmag.com >Kopia > >Ärende >RE: [MI-L] Number of fields > > > > > > >On 23 Jan 2006 at 22:27, Peter Horsbøll Møller <[EMAIL PROTECTED]> wrote: > >> As far as I remember there is a limit of 4000 bytes per record > >Ah, thank you Sir - you've probably just solved a long-standing problem >I've had. I have >a Microsoft Access table with only 56 fields that I call from MapInfo, but >found that I got >strange errors when adding a new field. I can't remember the actual error >message, >but it wasn't anything logical to me, and took ages to figure out that it >was caused by >this extra field being added. So, I went without the field, knowing that I >hadn't reached >the 255 field limit, but must have bumped into some other limitation. > >Dave >___ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l > >___ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Data size limits & optimization
Hi Tim MapInfo native Tables have a 2 GB file size limit for the DAT and MAP files. If your data is split into several layers, or separate Countries you may not hit this limit. However if you find you do hit the limit we have released a format that is similar to MapInfo TAB but the filesize limit is 16 Terrabytes rather than just 2 GB. Basically it uses 64 bit pointers instead of 32 bit pointers. At present we only have a translator ( free product ) from GML to this format, which we use to load full MasterMap coverage of Great Britain ( 68 GB in total ). However we are interested in looking at loading other large data sets. We could give you a free copy of MIMIC which allows the new 64 bit format to be viewed from within MapInfo Professional ( but not Map X at this time ). If any other listers are hitting the 2 GB limit we would be interested in loading your data into the new format. Please get in touch if this is of interest to you. Regards Bob @www.MapsByDesign.co.uk In message <[EMAIL PROTECTED] dcmx01.micromill.local>, Tim Smith <[EMAIL PROTECTED]> writes >Hi Listers, > >We are just about to purchase European wide Navteq Premium street >maps. Does anyone know if MapInfo (and MapX for that matter) can >handle this amount of data? >More specifically, as the data is going to be around 40GB, is >MapInfo cleaver enough to load only the parts that it needs to >display? This is important as my PC doesn't have 40GB of ram ;P > >Has anyone had experience with large areas of Navteq mapinfo maps? > >Cheers > >Tim > > > >___ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] distance between 2 polylines
Hi Chris I'm not aware of any short cuts MapBasic can help you with. You need to consider if you want the great circle (spherical) distance or straight line (cartesian) distance. Also do you want to take into account any known Z values ie slope distance. I hope there is a shorter way for you, but the only way I can think of at present is a bit longwinded. This would be first to write a function to get the distance between two lines. Having done this then write a routine to compare every line within one polyline with every line within the second polyline. The function to compare one line with another line would need to first check if they intersect ( ie distance = 0 ), then if not calculate distances from each end of one line with each end of other, and finally drop a perpendicular from each end of one line to the other line ( and check if the perpendicular position lies on the line, or an extension of the line - if an extension leave it out). You could use the MapBasic Distance command for point to point, particularly if you want spherical distance, but I don't think MapBasic offers much more than this. You could use an iterative solution using "buffer", but I think the direct method would be better. Its probably a couple of hours work, so worth waiting to see if any other listers know of any short cuts over this longwinded way!! Regards Bob @www.MapsByDesign.co.uk In message <[EMAIL PROTECTED]>, Christophe Brabant <[EMAIL PROTECTED]> writes >Hi everyone > >How could I compute, with Mapbasic language, the lowest distance >between two polylines ? > >Thank you > >Chris >___ >MapInfo-L mailing list >MapInfo-L@lists.directionsmag.com >http://www.directionsmag.com/mailman/listinfo/mapinfo-l -- bob young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] MI-L Tool for Batch Opening Large Amount of Tab Files
Hi John This is not the best way to cope with Landline, or any other large dataset. With both CAD and GIS systems it is best to have all similar objects such as roads on one single layer, all buildings on another single layer etc etc. Thus your dataset could reduce to the 63 layers that Landline contains or less if you want to combine some features like vegetation to a single layer. Most translators for Landline data and its replacement MasterMap would translate the data this way including our MapNTF and MapGML products. As you must have licensing to use this data you will presumably have access to the original NTF data. There is an evaluation copy of MapNTF on our website. By combining objects in such a fashion you can easily turn on and off visibility of a single set of features. You can also carry out text searches on the text layers. Further performance will be vastly better as only data that hits the screen will be read whereas the approach you are trying will need to open every file. Windows itself has a limit to how may files cab be opened at one time, and bear in mind MapInfo layers are made up of four files, and if indexed five files. Regards Bob .MapsByDesign.co.uk - Original Message - From: John Nott To: MapInfo-L@lists.directionsmag.com Sent: Tuesday, April 04, 2006 9:04 AM Subject: [MI-L] MI-L Tool for Batch Opening Large Amount of Tab Files Hello Listers, I have a massive amount of tab files (from a landline dataset). Which I would like to open to create a base map. However when I highlight all the files to open on the current map, MapInfo does nothing. If I select say 100 of the files to open, then they will open fine but as there are thousands it would take along time to open them this way. Has anyone come across this problem before? Are there any tools that will systematically open a folder full of tab files until they are all open? Any help would as always be very much appreciated. Thanks a million! - John ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] British National Grid Projection
Hi Ian This exact subject was discussed at the MapInfo User Group for UK and Ireland in Bristol recently. I've written a small paper about it and it can be downloaded from either our website at: www.MapsByDesign.co.uk or from the MUGUKI site at www.muguki.com I personally would recommend using a Bounds clause of (0,0) (200,200) which will give you a "step size" of exactly 1 millimetre and hold the Ordnance Survey values in MasterMap ITN,Address and Topo layers exactly. The values you use will have rounding errors up to about 6 millimetres. Regards - Original Message - From: Ian Hull To: MapInfo-L@lists.directionsmag.com Sent: Tuesday, April 11, 2006 4:57 PM Subject: [MI-L] British National Grid Projection Hi all, I'm currently using the following to setup my British National Grid projection - I'm not sure where the bounds clause came from and changing it makes slight differences to the output. I was just wondering what other UK users use as their projection and whether there is a "standard" in use. set CoordSys Earth Projection 8, 79, "m", -2, 49, 0.9996012717, 40, -10 Bounds (-7845061.1011, -15524202.1641) (8645061.1011, 4470074.53373)Regards,Ian HullSystems Team LeaderGreater Manchester Transportation UnitSalisbury HouseGranby RowManchesterM1 7AHInternal Tel: 815 2059Tel: 0161 455 2059Fax: 0161 455 2071E-mail: [EMAIL PROTECTED]Website: http://www.agma.gov.uk/Units/TransportUnit.htm** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. Please contact [EMAIL PROTECTED] with any queries. ** ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Created points are not shown on the map
Hi Sandy It looks like you might be passing to MapInfo the numeric values direct from the NMEA sentences of your GPS. These values are degrees and decimal minutes without separators. For example the value you have shown of: 35457900 would be 35 degrees 45.7900 minutes. MapInfo would expect to see this in decimal degrees - so for example in above you would need to divide the 45.79 by 60 and add this to degrees to get 35.76317. Regards Bob Young www.MapsByDesign.co.uk - Original Message - From: Sandy Flath To: mapinfo-l@lists.directionsmag.com Sent: Wednesday, August 02, 2006 2:35 PM Subject: [MI-L] Created points are not shown on the map Hello just a basic question. Christopher Brabante may already got this message.I´m a total newcomer: Why does the map not show my created points (they are GPS points and converted in decimal points like (+35457900 for e.g.) and I think I chose the right Longitude/Latitude Formate (wcs84). Meanwhile, opening the layers control, and manipulating the "etiquete" or let´s call it label, I still didn´t see the symbols of the created points (it could happen that I use strange words to describe because I work with the spanish language version of mapinfo).Does anybody know where the big problem is? -- begin: vcard Sr. Sandy Marzella Flath Adr.I: Albergue Juvenil "San Lorenzo de El Escorial" C/Residencia Nº14 E-28200 San Lorenzo de El Escorial Tfn.: 0034 91 8 905 924 0034 687 791 167 Adr. II: DaimlerChrysler España, S.A. Asesoría Económica Red Avenida Bruselas, 30 28108 Alcobendas (Madrid) España Tfno: +34 91 484 61 03 Fax: +34 91 484 61 29 Adr.III: Fam. Beck c/o Sandy Flath Am Fuchsbau 11 A D-64319 Pfungstadt Tel.: 0049 (0) 61 57 - 86 536 Mob.: 0049 0 176- 511 301 72 email: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] end:vccard Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit!"Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Points that are on mainland appear in the ocean
Hi Sandy If you are now entering the same coordinates into Google, and into MapInfo - and the coordinates are now correct then your base maps are also not matching Google. For example the area you are looking at might have accurate orthorectified photography whereas your MapInfo Map might be less accurate. Of course this could be the other way around as well. To test this you need to consider your zoom level and actual distances. For example if Google is only a matter of metres on land and MapInfo is only a matter of a metre or so in the sea, the coastline also would only have to be a mattter of metres inaccurate - quite likely with low cost, low accuracy mapping. Your GPS will probably be within about 10 metres of actual position. Some low cost datasets could be several kilometres from the correct position. Regards Bob - Original Message - From: Sandy Flath To: mapinfo-l@lists.directionsmag.com Sent: Thursday, August 03, 2006 12:15 PM Subject: [MI-L] Points that are on mainland appear in the ocean Dear Users,thank you for your help I got now the GPS points in the map apfter converting de degrees in decimal format. Checking google earth some points that showed up in mapinfo in the ocean, are situated on mainland in google earth, do I have to manipulate the scale ore anything else, to avoid that mapinfo places them in the ocean? -- begin: vcard Sr. Sandy Marzella Flath Adr.I: Albergue Juvenil "San Lorenzo de El Escorial" C/Residencia Nº14 E-28200 San Lorenzo de El Escorial Tfn.: 0034 91 8 905 924 0034 687 791 167 Adr. II: DaimlerChrysler España, S.A. Asesoría Económica Red Avenida Bruselas, 30 28108 Alcobendas (Madrid) España Tfno: +34 91 484 61 03 Fax: +34 91 484 61 29 Adr.III: Fam. Beck c/o Sandy Flath Am Fuchsbau 11 A D-64319 Pfungstadt Tel.: 0049 (0) 61 57 - 86 536 Mob.: 0049 0 176- 511 301 72 email: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] end:vccard Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit!"Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] OT - UK Trig Points
Title: Message Hi Tim There is a convertor on the OS site at GPS.GOV.UK. If you have Landline or MasterMap, particularly post PAI, this will give you very accurate Easting and Northing for any feature identifiable in your car park. Stats on accuracy of post PAI also on the website, but you are likely to be within a metre. You could use chainage and offset between two identifiable points to pick up other non-identifiable points. The free convertor will correct this BNG position to GPS lat long, for anywhere within the Country (GB). The method for the conversion is also available on the site, so its possible to program British National Grid Easting,Northing to Lat Long WGS84 ( ie GPS) or WGS84 to British National Grid Easting Northing. Its a great resource, and the only definitive correction, as only Ordnance Survey know where British National Grid is accurately! The correction is not just formulae. It uses a "look up" table that takes into account historic "features" of BNG which have to be taken into account to get correlation with GPS ( eg Use of old County Series maps and "features" introduced when these were stitched together to form BNG). My understanding is that Trig Points are no longer used in any OS Survey work and are therefore not maintained. I would therefore not recommend their use. Regards Bob Young www.MapsByDesign.co.uk - Original Message - From: Tim Smith To: mapinfo-l@lists.directionsmag.com Sent: Tuesday, August 15, 2006 2:19 PM Subject: [MI-L] OT - UK Trig Points Hi List. Does anyone know the best way to get an exact arbitrary lat/long position? e.g. I want to know the exact lat/long at a point in our carpark without using GPS. Are there any free resources that can give me a detailed aerial photo that gives accurate lat/long readings? How accurate are UK trig points? Kind regards Tim ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] How mapinfo loads map data
Title: Message Hi Tim In answering a question to you re: Lat Long and Trig points, I have now seen a list of your previous questions on MI L. In June you asked has anybody created a successful renderer of MapInfo tables. By Design have created two such products. ProPrinter was released in 1998 and renders MapInfo vector and raster tables. It can rotate both raster and vector and uses MapInfo spatial indexes as you were querying. Its a low cost viewer which compliments MapInfos products. We have also developed an enhanced 64 bit version of the RTREE spatial index used by MapInfo tables. This does not have a 2 GB limit. The limit is 16 Terrabytes for filesize. I sent copies of this to MapInfo about a year ago and they did some testing. The second renderer is for use on Pocket PC. This is called Maps4Site. This can view native MapInfo vector tables and ECW raster - same as ProPrinter. It also can view the enhanced 64 bit format. We have a free translator that will convert OS MasterMap to the 64 bit format. The whole of the UK can sit in one table, or as many layers as a user wants. Time to translate the whole of GB is under 8 hours on a laptop - ie the spatial index is not only fast on retrieval. I understand this is also the quickest translator to store National Coverage. Both products have been designed to compliment the use of MapInfo. Most of our customers have a site licence of ProPrinter and a VLP licence of MapInfo. We also developed an MBX ( with some C DLLs) that allow our 64 bit format to be viewed inside MapInfo Professional. So a MasterMap user with National Coverage can move anywhere in the Country with single ( non seamless ) tables. This can also export DXF allowing AutoCAD users to get map extracts for anywhere in the country. A chargeable version will write out Landline NTF format so that customers with legacy systems can get Landline NTF from MasterMap. Looking at your questions it seems like you have an interest in file size limits, seamless non seamless, spatial indexes etc so I thought above points might be of interest to you in answering your June question. Regards Bob - Original Message - From: Tim Smith To: Sent: Monday, June 05, 2006 10:07 AM Subject: [MI-L] How mapinfo loads map data Hi, I'm creating my own map renderer - much like MapX , using mitab. The question I have is regarding how mapinfo handles displaying large datasets. I guess it dynamically loads only what it needs to display, but how is this done? How does mapinfo know which features to load based on the area that you are trying to look at? More specifically, has anyone tried creating a map renderer, and have they (possibly with mitab) tried this before? Any level of help with this would be appreciated. Kind regards Tim (I'll ask specific mitab questions on its mailing list) ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
[MI-L] How MapInfo loads map data - June question
Hi Tim In answering a question to you re: Lat Long and Trig points, I have now seen a list of your previous questions on MI L. In June you asked has anybody created a successful renderer of MapInfo tables. By Design have created two such products. ProPrinter was released in 1998 and renders MapInfo vector and raster tables. It can rotate both raster and vector and uses MapInfo spatial indexes as you were querying. Its a low cost viewer which compliments MapInfos products. We have also developed an enhanced 64 bit version of the RTREE spatial index used by MapInfo tables. This does not have a 2 GB limit. The limit is 16 Terrabytes for filesize. I sent copies of this to MapInfo about a year ago and they did some testing. The second renderer is for use on Pocket PC. This is called Maps4Site. This can view native MapInfo vector tables and ECW raster - same as ProPrinter. It also can view the enhanced 64 bit format. We have a free translator that will convert OS MasterMap to the 64 bit format. The whole of the UK can sit in one table, or as many layers as a user wants. Time to translate the whole of GB is under 8 hours on a laptop - ie the spatial index is not only fast on retrieval. I understand this is also the quickest translator to store National Coverage. Both products have been designed to compliment the use of MapInfo. Most of our customers have a site licence of ProPrinter and a VLP licence of MapInfo. We also developed an MBX ( with some C DLLs) that allow our 64 bit format to be viewed inside MapInfo Professional. So a MasterMap user with National Coverage can move anywhere in the Country with single ( non seamless ) tables. This can also export DXF allowing AutoCAD users to get map extracts for anywhere in the country. A chargeable version will write out Landline NTF format so that customers with legacy systems can get Landline NTF from MasterMap. Looking at your questions it seems like you have an interest in file size limits, seamless non seamless, spatial indexes etc so I thought above points might be of interest to you in answering your June question. Regards Bob - Original Message - From: Tim Smith To: Sent: Monday, June 05, 2006 10:07 AM Subject: [MI-L] How mapinfo loads map data Hi, I'm creating my own map renderer - much like MapX , using mitab. The question I have is regarding how mapinfo handles displaying large datasets. I guess it dynamically loads only what it needs to display, but how is this done? How does mapinfo know which features to load based on the area that you are trying to look at? More specifically, has anyone tried creating a map renderer, and have they (possibly with mitab) tried this before? Any level of help with this would be appreciated. Kind regards Tim (I'll ask specific mitab questions on its mailing list) ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] OT - UK Trig Points
Title: Message
Hi Jim
Several of our programs, such as Maps4Site contain
the conversion. I could take out the basic conversion into a DLL that could be
called from MapBasic, and provide this free of charge as a download on our
website and MUGUKI.
Let me know if this would be of use. Due to other
commitments I would not be able to undertake the small amount of work
needed for about a week. This would be a function that you could pass BNG
node and get back WGS84 node. Also the reverse. You would need to add your
own code to get the coords for each polygon, polyline
etc.
Patrick at Blue Marble talks about Transformation.
Unless he has the look up table from Ordnance Survey embedded into his code he
cannot undertake the OSTN02 correction to get accurate results. As detailed
below this is not just formulae. The correction includes "historic errors". This
is why MapInfo gets the Transformation wrong and you are seeing your eleven
metre errors. The look up tables contain a correction for X,Y and Z for each 1
kilometre grid square within Great Britain.
Regards
Bob
- Original Message -
From:
Jim
Wilson
To: 'Bob Young' ; mapinfo-l@lists.directionsmag.com
Sent: Tuesday, August 15, 2006 5:58
PM
Subject: RE: [MI-L] OT - UK Trig
Points
Hi Bob and list,
Following on from the discussion below could I ask if
you or anyone else on the list knows how to convert polygons from BNG
into WGS84 using the definitive correction Bob mentioned
below?
The problem is that while we use GPS derived WGS 84
points, lines and polygons in field mapping, we occasionally also get OS data
in BNG.
As we are based in Scotland when I open a BNG and a
WGS 84 table in mapinfo the BNG data is offset by about 11 meters to the South
West due to the one transformation that Mapinfo uses and the offset that is
built in due to the historic features in BNG.
Does anyone know if there is any way to convert
a mapinfo table with the definitive correction mentioned
below?
TIA
-
Jim Wilson,
Hilton of Fern,
By Brechin,
Angus, Scotland. DD9 6SB
Phone
+44 (0)1356 650307
Fax +44 (0)1356
650445
Mobile +44 (0)7702 741516
email
[EMAIL PROTECTED]
web www.soilessentials.com
www.cropcircle.eu.com
-
From: Bob Young
[mailto:[EMAIL PROTECTED] Sent: 15 August 2006
14:48To: Tim Smith;
mapinfo-l@lists.directionsmag.comSubject: Re: [MI-L] OT - UK Trig
Points
Hi Tim
There is a convertor on the OS site at
GPS.GOV.UK.
If you have Landline or MasterMap, particularly
post PAI, this will give you very accurate Easting and Northing for any
feature identifiable in your car park. Stats on accuracy of post PAI also on
the website, but you are likely to be within a metre. You could use chainage
and offset between two identifiable points to pick up other non-identifiable
points.
The free convertor will correct this BNG
position to GPS lat long, for anywhere within the Country (GB).
The method for the conversion is also
available on the site, so its possible to program British National Grid
Easting,Northing to Lat Long WGS84 ( ie GPS) or WGS84 to British
National Grid Easting Northing.
Its a great resource, and the only definitive
correction, as only Ordnance Survey know where British National Grid is
accurately! The correction is not just formulae. It uses a "look up" table
that takes into account historic "features" of BNG which have to be taken
into account to get correlation with GPS ( eg Use of old County Series maps
and "features" introduced when these were stitched together to form
BNG).
My understanding is that Trig Points are no
longer used in any OS Survey work and are therefore not maintained. I would
therefore not recommend their use.
Regards
Bob Young
www.MapsByDesign.co.uk
- Original Message -
From:
Tim
Smith
To: mapinfo-l@lists.directionsmag.com
Sent: Tuesday, August 15, 2006 2:19
PM
Subject: [MI-L] OT - UK Trig
Points
Hi List.
Does anyone know the best way to get an exact
arbitrary lat/long position?
e.g. I want to know the exact lat/long at a
point in our carpark without using GPS. Are there any free resources
that can give me a detailed aerial photo that gives accurate lat/long
readings?
How accurate are UK trig
po
[MI-L] Snail mail
Hi list Does anybody else get very slow response and sometimes no response from MapInfo L and MITAB list ? A message I posted at 15:16 yesterday afternoon got to the MapInfoL list at 3:42 this morning. Thats over twelve hours and slower than the Royal Mail takes to deliver an envelope from Wales to Scotland! So I apologise for any duplicates from us on any list! Some replies appear virtually instantly! Also from answers posted I can see I quite often do not receive an original question and therefore presumably some of the replies. I have a folder for anti spam messages and they are not in there either. Any clues on the delays, and on the missing messages?? THis ones going at 11:02 BST ! Cheers Bob Young ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: re[2]: [MI-L] OT - UK Trig Points
Hi Patrick Sorry to have posted incorrect information on your product. When I last looked at your transformation I did not notice it could deal with shifts based on a grid. At least Jims aware of the issue, and has several choices now - which is one of the great things about the list. Thanks for letting me know. Best Wishes Bob - Original Message - From: "Patrick Cunningham" <[EMAIL PROTECTED]> To: "Bob Young" <[EMAIL PROTECTED]>; "Jim Wilson" <[EMAIL PROTECTED]>; Sent: Wednesday, August 16, 2006 1:22 PM Subject: re[2]: [MI-L] OT - UK Trig Points Bob, It is supported by the Geographic Calculator. To use the grid shift in the Calculator, there is an extra download that contains the OSTN02 grid file needed. Both an evaluation version of the Calculator and the OSTN02 grid file can be downloaded from our website at: http://www.bluemarblegeo.com/products/calculator.php?op=download If you have any other data conversion issues let us know. Patrick Hi Jim Several of our programs, such as Maps4Site contain the conversion. I could take out the basic conversion into a DLL that could be called from MapBasic, and provide this free of charge as a download on our website and MUGUKI. Let me know if this would be of use. Due to other commitments I would not be able to undertake the small amount of work needed for about a week. This would be a function that you could pass BNG node and get back WGS84 node. Also the reverse. You would need to add your own code to get the coords for each polygon, polyline etc. Patrick at Blue Marble talks about Transformation. Unless he has the look up table from Ordnance Survey embedded into his code he cannot undertake the OSTN02 correction to get accurate results. As detailed below this is not just formulae. The correction includes "historic errors". This is why MapInfo gets the Transformation wrong and you are seeing your eleven metre errors. The look up tables contain a correction for X,Y and Z for each 1 kilometre grid square within Great Britain. Regards Bob - Original Message - From: Jim Wilson To: 'Bob Young' mapinfo-l@lists.directionsmag.com Sent: Tuesday, August 15, 2006 5:58 PM Subject: RE: [MI-L] OT - UK Trig Points Hi Bob and list, Following on from the discussion below could I ask if you or anyone else on the list knows how to convert polygons from BNG into WGS84 using the definitive correction Bob mentioned below? The problem is that while we use GPS derived WGS 84 points, lines and polygons in field mapping, we occasionally also get OS data in BNG. As weare based in Scotland when I open a BNG and a WGS 84 table in mapinfo the BNG data is offset by about 11 meters to the South West due to the one transformation that Mapinfo uses and the offset that is built in due to the historic features in BNG. Does anyone know if there is any way to convert a mapinfo table with the definitive correction mentioned below? TIA - Jim Wilson, Hilton of Fern, By Brechin, Angus, Scotland. DD9 6SB Phone +44(0)1356 650307 Fax +44 (0)1356 650445 Mobile +44 (0)7702 741516 email[EMAIL PROTECTED] web www.soilessentials.com www.cropcircle.eu.com --------- From: Bob Young [mailto:[EMAIL PROTECTED] Sent: 15 August 2006 14:48 To: Tim Smith; mapinfo-l@lists.directionsmag.com Subject: Re: [MI-L] OT - UK Trig Points Hi Tim There is a convertor on the OS site at GPS.GOV.UK. If you have Landline or MasterMap, particularly post PAI, this will give you very accurate Easting and Northing for any feature identifiable in your car park. Stats on accuracy of post PAI also on the website, but you are likely to be within a metre. You could use chainage and offset between two identifiable points to pick up other non-identifiable points. The free convertor will correct this BNG position to GPS lat long, for anywhere within the Country (GB). The method for the conversion is also available on the site, so its possible to program British National Grid Easting,Northing to Lat Long WGS84 ( ie GPS) or WGS84 to British National Grid Easting Northing. Its a great resource, andthe only definitive correction, as only Ordnance Survey know where British National Grid is accurately! The correction is not just formulae. It uses a "look up" table that takes into account historic "features" of BNG which have to be taken into account to get correlation with GPS ( eg Use of old County Series maps and "features" introduced when these were stitched together to form BNG). My understanding is that Trig Points are no longer used in any OS Survey work and are therefore not ma
Re: [MI-L] Using do case...end case
Hi Nicky You are testing if either end of a line is concident with one of two points. There are four possible results. To recode as a do case statement have an integer value for result of test eg lnResult which starts life as 0. If end 1 is conincident then add 1 to result ie lnResult = lnResult + 1 If end 2 is coincident then add 2 to result ie lnResult = lnResult + 2 ( If you had a third test add 4, a fourth test add 8 and so on) Now you can recode as a do case statement. For readability you might choose to code as case 0 case 1 case 2 case 3 but for speed put the most likely result first and the least likely result as the last test in the case statement. To find most likely result you could use real data and put counters in the case statement. So you might get: case 3'// most likely case 0 case 2 case 1 '// least likely You do not seem to be allowing any tolerance in your test for coincidence. When you are testing if X1 = X2 and especially if the values are floating point, it is worth considering adding a tolerance. This might be just 1 millimetre but gives flexibility to your program. So the test might be: lfTolerance = 0.005 '// ie 5 millimetre if abs ( lfX1 - lfX2 ) > lfTolerance then lnResult = lnResult + 1 end if MapBasic is not very quick. So always avoid going through any unneccesary code and avoid duplicate computations in if statements. Offloading intensive computations to a C based DLL will speed up code significantly, and is easy to link back to MapBasic through Declare Function statements. Hope these thoughts are useful to you. Regards Bob Young - Original Message - From: "Nicki Cozens" <[EMAIL PROTECTED]> To: Sent: Wednesday, August 16, 2006 3:08 PM Subject: [MI-L] Using do case...end case Dear Listers I have written some code with several nested if and elseif statements. My code is running pretty slowly, probably as a result, and I would like to do something to rectify this. The only problem is that I'm not really sure how to! I believe that do case statements are more efficient than ifs but I'm not really sure how to use them. For example, is it possible to re-write: If (ObjectnodeX(a_linelist(myline), 1,zz)) = ObjectnodeX(a_intersecting_point, 1, 1) and (ObjectnodeY(a_linelist(myline), 1,zz)) = ObjectnodeY(a_intersecting_point, 1, 1)then using a do case, or is there a better way to do this? Similarly can I re-write the following statements: If ((a_startx = a_x_1) and (a_starty = a_y_1)) or ((a_endx = a_x_1) and (a_endy = a_y_1)) then X1y1_flag = true End If If ((a_startx = a_x_2) and (a_starty = a_y_2)) or ((a_endx = a_x_2) and (a_endy = a_y_2)) then X2y2_flag = true End If If (a_x1y1_flag) and (a_x2y2_flag) then DO SOMETHING elseif ((a_x1y1_flag)= true) and ((a_x2y2_flag)=false) then DO SOMETHING ELSE elseif ((a_x2y2_flag)= true) and ((a_x1y1_flag)= false) then DO SOMETHING ELSE end if using a do case? Many thanks Nicki Cozens Data Management Officer Highways Development Control Leicestershire County Council ___ Leicestershire County Council - rated a 'four-star' council by the Audit Commission ___ This e-mail and any files transmitted with it are confidential. If you are not the intended recipient, any reading, printing, storage, disclosure, copying or any other action taken in respect of this e-mail is prohibited and may be unlawful. If you are not the intended recipient, please notify the sender immediately by using the reply function and then permanently delete what you have received. Incoming and outgoing e-mail messages are routinely monitored for compliance with Leicestershire County Council's policy on the use of electronic communications. The contents of e-mails may have to be disclosed to a request under the Data Protection Act 1998 and the Freedom of Information Act 2000. The views expressed by the author may not necessarily reflect the views or policies of the Leicestershire County Council. Attachments to e-mail messages may contain viruses that may damage your system. Whilst Leicestershire County Council has taken every reasonable precaution to minimise this risk, we cannot accept any liability for any damage which you sustain as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Using do case...end case
Hi Nicky Just a quick amendment to that code! It should of course read: if (lfX1 - lfX2) < lfTolerance then lnResult = lnResult + 1 end if with regard to my suggested solution, and not if greater than. You could further optimise the ifs so that the least likely result causes the increment. Then the least likely result of all would end up as case 0. THis mean the most likely result would not run the code within the ifs. Regards Bob - Original Message - From: "Nicki Cozens" <[EMAIL PROTECTED]> To: Sent: Wednesday, August 16, 2006 3:08 PM Subject: [MI-L] Using do case...end case Dear Listers I have written some code with several nested if and elseif statements. My code is running pretty slowly, probably as a result, and I would like to do something to rectify this. The only problem is that I'm not really sure how to! I believe that do case statements are more efficient than ifs but I'm not really sure how to use them. For example, is it possible to re-write: If (ObjectnodeX(a_linelist(myline), 1,zz)) = ObjectnodeX(a_intersecting_point, 1, 1) and (ObjectnodeY(a_linelist(myline), 1,zz)) = ObjectnodeY(a_intersecting_point, 1, 1)then using a do case, or is there a better way to do this? Similarly can I re-write the following statements: If ((a_startx = a_x_1) and (a_starty = a_y_1)) or ((a_endx = a_x_1) and (a_endy = a_y_1)) then X1y1_flag = true End If If ((a_startx = a_x_2) and (a_starty = a_y_2)) or ((a_endx = a_x_2) and (a_endy = a_y_2)) then X2y2_flag = true End If If (a_x1y1_flag) and (a_x2y2_flag) then DO SOMETHING elseif ((a_x1y1_flag)= true) and ((a_x2y2_flag)=false) then DO SOMETHING ELSE elseif ((a_x2y2_flag)= true) and ((a_x1y1_flag)= false) then DO SOMETHING ELSE end if using a do case? Many thanks Nicki Cozens Data Management Officer Highways Development Control Leicestershire County Council ___ Leicestershire County Council - rated a 'four-star' council by the Audit Commission ___ This e-mail and any files transmitted with it are confidential. If you are not the intended recipient, any reading, printing, storage, disclosure, copying or any other action taken in respect of this e-mail is prohibited and may be unlawful. If you are not the intended recipient, please notify the sender immediately by using the reply function and then permanently delete what you have received. Incoming and outgoing e-mail messages are routinely monitored for compliance with Leicestershire County Council's policy on the use of electronic communications. The contents of e-mails may have to be disclosed to a request under the Data Protection Act 1998 and the Freedom of Information Act 2000. The views expressed by the author may not necessarily reflect the views or policies of the Leicestershire County Council. Attachments to e-mail messages may contain viruses that may damage your system. Whilst Leicestershire County Council has taken every reasonable precaution to minimise this risk, we cannot accept any liability for any damage which you sustain as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Limit to Region Styles?
Hi Ann To keep the MAP file compact MapInfo stores a single byte flag for style information against each object. This byte is then a pointer into a look up table for the appropriate style be it region, line, point or text. As a single byte is used this limits the number of styles to 255 for any particular object in any single table. This principle dates right back to 1986 when disk size and storage was much more critical than it is now. I've never tried this, but perhaps you could use a seamless table to split your master table into subsets of 255 or less styles. The owner of the data would need to know which base table to edit, but I suspect it could then be viewed a single layer by users. Regards Bob - Original Message - From: Moulding, Ann To: mapinfo-l@lists.directionsmag.com Sent: Wednesday, August 16, 2006 5:05 PM Subject: [MI-L] Limit to Region Styles? I was creating a legend (as a MapInfo table) for a Geological Map (522 records with different brush styles) using a Mapbasic routine. At record 265 the region style created and displayed by Mapinfo began to behave somewhat randomly (in some cases it created a polygon with the correct style but for most polygons it had a different pattern, foreground and background color). When I split the file into 2 files of 260 records and ran the routine it correctly assigned the shade patterns. In addition, when I tried to edit some of the regions created from the 522 record file Mapinfo did not recognize the changes unless I changed the pattern, foreground and background. I am wondering if there is a limit to the number of brush styles MapInfo can store in a table, or display. Could this be some type of a bug?? In some cases I would create the regions with the correct brush style then zoom in or out and the style would change. Appreciate any insight or help with this. Ann Moulding GIS Specialist, Geologic Mine Services TXI Operations Office: (972)-647-3827 Cell: (214)-502-0551 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Exporting topographic contours to DXF
Hi Arne MapInfo only stores X and Y as geometry - its a 2D system. Therefore your Z value must be an attribute in the DAT file rather than an ordinate in the MAP file. AutoCAD is a true 3D system and Z has the same status as X and Y. So you need an export that "knows" it needs to take a field called Z ( or height or whatever it is ), possibly convert from a string to a float value and put into the Z value for EACH node on the contour line. I'm sure options are available, but this is why you are having a problem with a "standard" export. Regards Bob - Original Message - From: "Arne Scherrenberg" <[EMAIL PROTECTED]> To: Sent: Thursday, August 17, 2006 9:03 AM Subject: [MI-L] Exporting topographic contours to DXF Dear listers, Does anyone know why the z-values disappear when exporting a topographic contour map from MapInfo to DXF? I have used the universal translator and exported to various autocad versions, and ticked the box keeping the attribute data. But I always loose the z-values, actually I loose all other infomation. That is, all extra data is lost, and I am left with just lines in x and y space, NOT in x, y, z space with alll colours and other attributes! Can anybody please help solve this? Cheers, Arne ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Using do case...end case
Hi Nicky Yes, thats right. Run the if statements first to establish the correct value for lnValue. Then run the case statement. In theory this should be faster, as when a match is found in the case statement, the interpreter should junp to the bottom of the loop - thats why its best to put the most likely result first. So I would expect this to be faster. However I have found the only sure way to optimise code for speed is to try alternatives that you think might be candidates and actually time them on real data. Sometimes the results are surprising. Conversions of strings to float for example slow up code. MapBasic is not compiled to machine code, only tokenised code. So the language is "interpretted" at run time and therefore will not necessarily offer similar optimisations for if-endif case etc as a true compiler would. On the other hand because it is an interpretted language it is slow - so optimising the code is worth the time where you have a slow application. If you are looping over and over through data so time delays are several seconds or even minutes, use the timer function in MapBasic to get the actual time taken and then try optimising the code. On if statements make the least likely result run the code where this is an option as mentioned yesterday. One potential snag to be aware of though is that if your code accesses files off disk the first run will be slower than the second and subsequent runs because the operating system will cache the file - even if you do not change the code. So do not do the comparison timings on the first access to the files!! Consider printing out imtermediate times, if you have poor performance and cannot work out where the time is going. You could even put two alternatives in the same code by use of functions - and call both functions to compare them. If you decide to add the tolerance test on your line coincidence take the absolute value of the difference and test if its less than your tolerance ie if abs( lfX1 - lfX2) < lfTolerance then Regards Bob - Original Message - From: "Nicki Cozens" <[EMAIL PROTECTED]> To: "Bob Young" <[EMAIL PROTECTED]>; Sent: Thursday, August 17, 2006 8:29 AM Subject: RE: [MI-L] Using do case...end case Hi Bob Many thanks for your message, can I check to see if I am following you correctly? Do I still run the if statements at the beginning, like so: lnresult = 0 If (a_startx = a_x_1) then lnresult = lnresult+1 end if If (a_starty = a_y_1) then lnresult = lnresult+2 end if etc And then run the do case... Do case lnresult Case 1 Do something Case 2 Do something else Etc End Case And if so, is this more efficient than having numerous tests in the if statement? Many thanks Nicki -Original Message- From: Bob Young [mailto:[EMAIL PROTECTED] Sent: 16 August 2006 16:10 To: Nicki Cozens; mapinfo-l@lists.directionsmag.com Subject: Re: [MI-L] Using do case...end case Hi Nicky Just a quick amendment to that code! It should of course read: if (lfX1 - lfX2) < lfTolerance then lnResult = lnResult + 1 end if with regard to my suggested solution, and not if greater than. You could further optimise the ifs so that the least likely result causes the increment. Then the least likely result of all would end up as case 0. THis mean the most likely result would not run the code within the ifs. Regards Bob - Original Message - From: "Nicki Cozens" <[EMAIL PROTECTED]> To: Sent: Wednesday, August 16, 2006 3:08 PM Subject: [MI-L] Using do case...end case Dear Listers I have written some code with several nested if and elseif statements. My code is running pretty slowly, probably as a result, and I would like to do something to rectify this. The only problem is that I'm not really sure how to! I believe that do case statements are more efficient than ifs but I'm not really sure how to use them. For example, is it possible to re-write: If (ObjectnodeX(a_linelist(myline), 1,zz)) = ObjectnodeX(a_intersecting_point, 1, 1) and (ObjectnodeY(a_linelist(myline), 1,zz)) = ObjectnodeY(a_intersecting_point, 1, 1)then using a do case, or is there a better way to do this? Similarly can I re-write the following statements: If ((a_startx = a_x_1) and (a_starty = a_y_1)) or ((a_endx = a_x_1) and (a_endy = a_y_1)) then X1y1_flag = true End If If ((a_startx = a_x_2) and (a_starty = a_y_2)) or ((a_endx = a_x_2) and (a_endy = a_y_2)) then X2y2_flag = true End If If (a_x1y1_flag) and (a_x2y2_flag) then DO SOMETHING elseif ((a_x1y1_flag)= true) and ((a_x2y2_flag)=false) then DO SOMETHING ELSE elseif ((a_x2y2_flag)= true) and ((a_x1y1_flag)= false) then DO SOMETHING ELSE end if using a do case? Many thanks Nicki Cozens Data Management Officer Highways Development Control Leicestershire County Council ___ Leicestershi
Re: [MI-L] area calculation discrepancies
Hi Cathy I hope the following is of some use, although even taking into account these factors I get another set of numbers none of which match exactly! The corrrect area mathematically ( PI * R * R ) is 3,141,593 for a non earth projection ie as a CAD system would compute it. You can ask MapInfo to compute either the spherical area or the cartesian area. If you want to get a "mathematical" match with PI * R^2 then you need to use cartesian. When using update column use CartesianArea function rather than Area function (which returns spheroid area). ( This does work accurately for rectangles and polygons). There are also two ways you could create the circle. The best result should come form holding down shift key and drawing an ellipse. I say should because this would be stored internally in MapInfo as a centre point and a radius, and so should be able to be computed accurately. If you use this method the double click does NOT return the area, so I suspect you did not use this method. The alternative method is to use the buffer command, and set the smoothness to maximum of 100. A snag with this method is that this is not stored as a true circle but as a threepenny bit ie with 100 flats. The area will therefore not be correct. This type of object WILL report its area with a double click. If you have imported the object from some other system this might also account for why your area is reported with a double click. With either type of object, using cartesian ( or spherical ) I cannot get an exact match but I get closer agreement to the correct cartesian value of 3,141,593 with 3,139,567 for a true circle ( shift key method ) and 3,139,526 for buffer of a point method with maximum smoothness ( both got from update column and CartesianArea function). A 1 km square returns exactly the correct answer of 1,000,000 providing you stick with cartesian. You can set the map window to use cartesian using Options... off the map menu. You can reset the radius etc by double clicking when the layer containing the object is editable. Hopefully someone will throw some light on the 0.07% error on the circle. Regards Bob - Original Message - From: COLDREY, Cathy (Bristol) To: mapinfo-l@lists.directionsmag.com Sent: Wednesday, August 23, 2006 5:34 PM Subject: [MI-L] area calculation discrepancies Hi List, Does anyone have much experience in calculating areas of polygons or circles in MapInfo? My problem is this. I have a 1 km radius which has exactly a diameter of 2km, meaning a 1 km radius. Now mathematically the area of theis would be 3136860 square m. But if I use the update column option the number I get is 3118630 square m or double click on the object I get 3119000 square m. I am using British national grid projection. Can anyone explain to me why I get three differing numbers? And also how will I find the correct areas of several other polygons that are not circular? Thanks for any help you can provide to this mystery. :) cathy Cathy ColdreyGeomatics Specialist, EuropeWorleyParsons KomexEnvironment & Water Resources Tel: + 44 (0)117 9105 124Fax: + 44 (0) 117 9105 1393-8 Redcliffe Parade WestBristol BS1 6SPRegistered No. 2718875www.worleyparsons.com Please note: effective immediately my new e-mail address is[EMAIL PROTECTED] *** WORLEYPARSONS GROUP NOTICE *** PRIVILEGED AND CONFIDENTIAL ***"This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this email in error, please notify us immediately by return email and delete the email and any attachments. Any personal views/opinions expressed by the writer may not necessarily reflect the views/opinions of the company."Thank you. ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] area calculation discrepancies
Hi David The results I listed in my 24/6 email were with an internal step size of 1 mm. This is the step size I would recommend for Great Britain, and also now supported as standard in MapInfo, as it allows exact storage of MasterMap Topo and ITN data as discussed many times before. With a step size of 1 millimetre this is exactly divisable into any whole number so of metres and of course kilometres. Kathys original question, and my tests were for a radius of 1 km or 1 million steps exactly. Even if the step size was the old default of 6.22 millimetres or thereabouts, it would not account for the error seen of 0.07% on a radius of 1 kilometre - in fact it would only give an error of about 0.0006%. So the question still remains why MapInfo set to Cartesian gets polygons with straight sides, eg rectangle spot on, but gets a circle to only within 0.07%. With respect I think Cliff is incorrect on this rare occasion as using cartesian the world is flat, as far as MapInfo is concerned! Hence the square and rectangle gets the exact result with an internal step size of 1 millimetre and sizes in exact kilometres as originally stated. Cliffs reply is I think relevant when using "spheroid" area values. Regards Bob - Original Message - From: David Hilpipre To: Ian Robertson ; Mapinfo-L@lists.directionsmag.com Cc: [EMAIL PROTECTED] Sent: Friday, August 25, 2006 2:35 PM Subject: RE: [MI-L] area calculation discrepancies Hello, Wouldn't it have something to do with map internal precision as well ? With non earth projection, it depends on the bounds. If the bounds are 0 to 2000m in X and Y, then the internal precision is 2000m / 2147483648 = approx 1/1 of a milimeter ; less than the size of a bacteria ?? ;-) (2147483648 = 2^(32-1) which is, if my memories serves me right, the number of unique position that mapinfo can store between two bounds. I thinks it's the size of a signed (hence minus 1) integer on a 32bit computer ... I believe...) In this case, the size of the rectangle is really 400 sq m If the bounds are standard mapinfo bounds, then Mapinfo maps can't make two distinct points less than 0.1154 m apart AFAIR (4 inches more or less) in a earth projection. There's then no way to be sure that a rectangle of 2000 m by 2000m is not something like 1999.96 or 1999.97 or ... or 2000.04 or 2000.05 once converted to a polygon? for example, 2000.05 x 2000.05 = 4000200 sq m, which is almost what Mapinfo calculates (cartesian calculation !) if you make the map more accurate (by reducing the bounds) to a precision of, let's say half a milimeter, then the same square has an area of 400,5 sq m. Still not 400, but much closer There was a excellent document of Jacques PARIS that explains internal precision of Mapinfo Maps Hope this helps as well De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ian RobertsonEnvoyé : vendredi 25 août 2006 11:31À : Mapinfo-L@lists.directionsmag.comCc : [EMAIL PROTECTED]Objet : RE: [MI-L] area calculation discrepancies Cathy & Vick, I have come across this problem too and it seems to re-occur from time to time. Having discussed this with a my surveying colleague we'd offer the following observations: MapInfo doesn't calculate the area of a circle, it converts it to an inscribed polygon with 101 sides which produces a underestimate as Vick points out. We got a figure of 3,139,566.7 There are also problems with rectangles. Again MapInfo will not calculate the area of a rectangle object it has to be converted to a polygon, but this is less problematic. Nevertheless, even with a non-earth projection MapInfo returns a value of 4,000,000.5 sq m for a square of side 2000m. My colleague tells me a similar problem can occur with AutoCAD and suggests the cause of the error is due to the method of triangulation. IF MapInfo uses triangulation with isosceles triangles then there would be small excess slithers at either end causing an overestimation this time. This method is popular because the area of the triangles can be easily calculated with 0.5 * base * height. Hope this sheds a little more light on the subject. Ian Hello Cathy,I'll bow to Clifford's extensive knowledge on this subject, but in terms ofusing MapInfo Pro, there are a few things to be aware off.The British national grid system is indeed a Transverse Mercator projectionwhich give a Cartesian coordinate space to work with. That is to say, it'sjust a simple grid with parallels lines in x/y, or Eastings/Northings, andperpendicular axis. Assuming you're happy to accept the errors associatedwith this projection (which is a 2D simplification
[MI-L] Network problem
Dear List One of our customers is occasionally getting this message:- Table xyz has been changed by another program and must be reopened. The files are being accessed from a server running Windows 2003 Server. The user is running MapInfo version 7.8 on Windows XP. They assure me that they are the only user and only application accessing the MapInfo table. The table is a native MapInfo table - not linked to Excel or Access. One possibility is that their original files are corrupt and I am planning to check this. Has anyone else experienced similar problems? Regards Bob MapsByDesign.co.uk ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Problem with co-ordinates... Help please ???
Title: Problem with co-ordinates... Help please ??? Hi Stuart Perhaps your map projection is not simple lat long. For example if you are using Transverse Mercator projection then fixed offsets in degrees will not be equal distances apart and lines of longitude and latitude will form curves. Regards Bob MapsByDesign.co.uk - Original Message - From: Gibb, Stuart To: mapinfo-l@lists.directionsmag.com Sent: Monday, October 16, 2006 5:19 PM Subject: [MI-L] Problem with co-ordinates... Help please ??? All, I am using the following snippets of code to create fixed width band regions at 90 degrees to a series of given straight lines. The lines contain numerical data which I can then thematically map. I also have a version that creates variable width bands but for the moment I'll assume all bands are the same width. After a lot of tweaking I thought I had finished the tool...Unfortunately, after crudely holding the corner of a sheet of paper up to the screen it appears my bands aren't perfectly perpendicular to the original line though I am clueless as to what could have gone wrong Is there any error converting degrees to radians and then back again in MapInfo ? Also, I am the using British national grid co-ordinate set, could this where my slight discrepancy has come from multiplying ? fFNodeX = ObjectNodeX(oLine, 1, 1) ' read longitude fFNodeY = ObjectNodeY(oLine, 1, 1) ' read latitude fTNodeX = ObjectNodeX(oLine, 1, k) ' read longitude fTNodeY = ObjectNodeY(oLine, 1, k) ' read latitude fA1 = fTNodeX - fFNodeX fA2 = fTNodeY - fFNodeY fLinkLength = SQR(fA1*fA1 + fA2*fA2) fB1 = -fA2/fLinkLength fB2 = fA1/fLinkLength x1 = fFNodeX + (fB1 *(fWidth + fOffset)) y1 = fFNodeY + (fB2 *(fWidth + fOffset)) x2 = fTNodeX + (fB1 *(fWidth + fOffset)) y2 = fTNodeY + (fB2 *(fWidth + fOffset)) x3 = fTNodeX + (fB1 * fOffset) y3 = fTNodeY + (fB2 * fOffset) x4 = fFNodeX + (fB1 * fOffset) y4 = fFNodeY + (fB2 * fOffset) As always, any help would be greatly appreciated Many thanks Stu Visit our website at http://www.halcrow.com The contents of this email are confidential, for the sole useof the intended recipient at the email address to which it hasbeen addressed and do not give rise to any binding legalobligation upon Halcrow companies unless subsequently confirmedon headed business notepaper sent by fax, letter or as an emailattachment. Whilst reasonable care has been taken to avoid virustransmission, no responsibility for viruses is taken and it isyour responsibility to carry out such checks as you feelappropriate. Emails supplied are as found and there's noguarantee that the messages contained within the body of theemail have not been edited after receipt. If you receive thisemail in error, please contact the sender immediately and deletethe message from your system.Thank you.- ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Project Grande Terminated?
Hi Uffe I would not have thought this was a contributing factor. In fact I would have the thought the graphics capability of .NET was one of the original drivers to start the .NET Project Grande. The old Windows API calls are presented at a higher more usable level but because of DirectX support are if anything more performant than the older API calls which did not use DirectX. For example raster rotation is a doddle in .NET but was a few weeks work using older APIs!. I know its a "hobby horse" of mine and will generate a few groans but the speed would not drop to that of Arc because of the native TAB format and the RTREE index. Even if you use inefficient VB5 calls to draw the graphics the speed is fine because you are only reading and drawing the "onscreen" vectors - and .NET is faster than those VB5 calls. One of the MI jewels. Perhaps now more resources can go into taking the TAB format to 64 bit!? Regards Bob MapsByDesign.co.uk - Original Message - From: "Uffe Kousgaard" <[EMAIL PROTECTED]> To: "'Mapinfo-L'" Sent: Friday, October 20, 2006 10:55 AM Subject: Re: [MI-L] Project Grande Terminated? It is quite some time I saw these demos and they were based on rather small datasets and very limited functionality in the user interface. I hear from many others that the GUI of .NET applications can be quite slow, where you can even see the visual items being drawed on the screen. And I guess a GIS application would be especially prone to such a problem. But a few more details from Moshe Binyamin would be interesting. Regards Uffe - Original Message - From: "SCISOFT" <[EMAIL PROTECTED]> To: "'Uffe Kousgaard'" <[EMAIL PROTECTED]>; "'Mapinfo-L'" Sent: Friday, October 20, 2006 11:42 AM Subject: RE: [MI-L] Project Grande Terminated? Uffe I haven't seen PG demos run - was it so slow? .NET isn't inherently slow. Was it the panning and screen updating, perhaps? IL Thomas GeoSciSoft - Perth, Australia -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Uffe Kousgaard Sent: Friday, October 20, 2006 4:10 PM To: Mapinfo-L Subject: Re: [MI-L] Project Grande Terminated? Dear all, My guess is MapInfo Corp. stopped the project because we could have ended up with something even slower than ArcGIS. That would have been a disaster for the product. The existing user interface isn't that bad, so you have to look at pro's and con's. Remember the grass isn't always greener on the other side, once you get there. Let's hope they start working on a 64-bit native version instead of going the slow .NET route. Perhaps even with some of the desired improvements included. As a developer of 3rd party add-ons for MapInfo (RouteFinder in particular), this also has the implication we can spend our resources on adding new functionality in future versions instead of rewriting code. And a big thanks to Moshe Binyamin for letting us know, what is going on. Kind regards Uffe Kousgaard www.routeware.dk ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] MI: Style Override Bug
Hi Eric
When I encountered these two problems it seemed
that they behaved "quad state" with MapInfo Professional.
For example the zoom layer issue seems to be able
to be:
Display off and without zoom
layer set
Display on and without zoom
layer set
Display off and zoom layer set
Display on and zoom layer
set
One possible solution for a future MapInfo that
would be backward compatible would be to use a comment line. For example if the
user wanted to save zoom layering set but display off a line could be
written out:
! OFF ZOOM ( 0, 500 ) Units
"m"
Older versions of MapInfo would ignore this
particular comment, allowing backward compatibility. Newer versions could
interpret it however you design it. The above example would open up with
visibility off but if the user turned on visibility it would be with zoom layer
set.
A comment line starting "!" that isn't a newly
defined command could still be ignored allowing "forward backward
compatibility".
Regards
Bob
MapsByDesign
- Original Message -
From:
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
; mapinfo-l@lists.directionsmag.com
Sent: Saturday, October 21, 2006 8:40
PM
Subject: Re: [MI-L] MI: Style Override
Bug
Lars and all,
This bug has nothing to do with the fact
that a workspace is a script/macro. And the decision of whether to write out
unused properties is always a judgment call and again has nothing to do with
the structure of a workspace. In this particular case, the unused style
properties are written out! So, the issue is not the properties of the style
overrides but rather that the knowledge of the style override flag is not
written out. Here's a snippet of the MapBasic in the workspace.
Set Map Layer
1 Display Off Global
Pen (1,2,0) Brush (2,16777215,16777215) Symbol
(51,0,12,"MapInfo
Oil&Gas",0,0) Line (1,2,0) Font ("Arial",0,9,0)All the styles of all four
types (area/region (brush and pen), line(pen), point(symbol) and text(font)
are written out. Note that this practice is quite old and has
occasionally been called into question. A customer some time ago wanted
to know why their default styles (set in preferences) were not taking effect.
The reason was that they had loaded an old workspace that had these unused
override styles in them. However, I digress. The problem in this case is that the MapBasic for
handling visibility and style override do not match the capabilities of the
user interface! The possible options after Display are Off (invisible),
Graphic (visible use styles from data) and Global (use style override). This
tri-state model does not support remembering whether a style override was ever
used. When a workspace is read in with the Off state and the user enables the
visibility checkbox, the code essentially takes a guess and turns it back to
Graphic. You can all see this from the MapBasic window.
Therefore, to fix this problem, the
MapBasic would have to be enhanced to allow a new Boolean property
(styleoverride?) that would hold this state and the visibility state would
just be Off and Graphic (or Off and On). We could change MapInfo
Professional to always write out the new syntax which would push up the
workspace version. However, this might happen for other reasons in that
release so that might not matter. When we do this, we try to handle backward compatibility as best we
can. We would continue to understand the old syntax (Global and even Graphic)
and I suppose could even support the redundant Global and StyleOverride On
states. Using Global and StyleOverride Off would certainly be an error.
This would mean that any existing workspaces are not going to see an
improvement, just new ones. Whenever we change these things, all the possible
states have to be looked at, so there may be a hole in some of this. One thing
we try to avoid, but can do, is check the version of the MapBasic program or
workspace and decide what syntax is appropriate. However, this has a
shortcoming in that folks with large programs who recompile for a newer
version would get an error if they used the old syntax. So, we try and stay
away from this if possible. Just
to complicate things (I seem to be good at that), there is another layer
property that I think should be a tri-state and is not. Perhaps this is
because Global/Graphic was already there. This is the layer zoom property! It
has always seemed to me that layer visibility is a tri-state logically. The
layer is either always visible, never visible or maybe visible. A perfect
tri-state! So, to make sure that a layer is visible, one must turn Visibility
on (Graphic or Global) and then make sure that zoom is off. You can forget
that last step the layer might be visible or it might not. It would seem that
the though
Re: [MI-L] MI: Style Override Bug
Hi Eric
Following my earlier email on this I have done
some testing with MapInfo version 6.5 and version 8.0.
When I first encoutered these problems about
eight years ago I am 99% sure that a MapInfo workspace could not remember the
setting for display off and a zoom layering setting. In other words a user
could NOT open up a workspace with display off and then when turning on the
display immediately get zoom layering from a saved setting in the
workspace.
Testing this on both 6.5 and 8.0 this morning this
is now possible! In other words you are remembering quad state for zoom layering
and I believe this is what users want with zoom layering - AND with style
override.
The reason it works with zoom layering is that as
well as the display setting of ON, GRAPHIC and GLOBAL. The Zoom layer line can
be:
Zoom (1,1000) Units "km" Off
or
Zoom (1,1000) Units "km"
The absence of the word Off is interpreted as on
and therefore you are holding the four possible values for
Display on Zoom Layering On
Display off Zoom Layering On
Display on Zoom Layering off
Display off Zoom Layering Off
Therefore could the solution to the style override
be dealt with in a consistent manner by adding the word Off to the end of the
style override line ie
Global Pen(1,2,0) Line (1,2,0) OFF
If I am correct that earlier versions ( 8 years
ago) did not have the quad state for Zoom Layering then you have at some time
added the OFF option to the Zoom Keyword and this did not cause problems to the
interpreter in older versions?? ( Unfortunately I have not got version 4.5 or
similar loaded to test this ).
I think it would be good that the zoom layering and
the style override work in a consistent way and personally I think quad state
like the current zoom layering would be the best for users.
Regards
Bob
MapsByDesign
- Original Message -
From:
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
; mapinfo-l@lists.directionsmag.com
Sent: Saturday, October 21, 2006 8:40
PM
Subject: Re: [MI-L] MI: Style Override
Bug
Lars and all,
This bug has nothing to do with the fact
that a workspace is a script/macro. And the decision of whether to write out
unused properties is always a judgment call and again has nothing to do with
the structure of a workspace. In this particular case, the unused style
properties are written out! So, the issue is not the properties of the style
overrides but rather that the knowledge of the style override flag is not
written out. Here's a snippet of the MapBasic in the workspace.
Set Map Layer
1 Display Off Global
Pen (1,2,0) Brush (2,16777215,16777215) Symbol
(51,0,12,"MapInfo
Oil&Gas",0,0) Line (1,2,0) Font ("Arial",0,9,0)All the styles of all four
types (area/region (brush and pen), line(pen), point(symbol) and text(font)
are written out. Note that this practice is quite old and has
occasionally been called into question. A customer some time ago wanted
to know why their default styles (set in preferences) were not taking effect.
The reason was that they had loaded an old workspace that had these unused
override styles in them. However, I digress. The problem in this case is that the MapBasic for
handling visibility and style override do not match the capabilities of the
user interface! The possible options after Display are Off (invisible),
Graphic (visible use styles from data) and Global (use style override). This
tri-state model does not support remembering whether a style override was ever
used. When a workspace is read in with the Off state and the user enables the
visibility checkbox, the code essentially takes a guess and turns it back to
Graphic. You can all see this from the MapBasic window.
Therefore, to fix this problem, the
MapBasic would have to be enhanced to allow a new Boolean property
(styleoverride?) that would hold this state and the visibility state would
just be Off and Graphic (or Off and On). We could change MapInfo
Professional to always write out the new syntax which would push up the
workspace version. However, this might happen for other reasons in that
release so that might not matter. When we do this, we try to handle backward compatibility as best we
can. We would continue to understand the old syntax (Global and even Graphic)
and I suppose could even support the redundant Global and StyleOverride On
states. Using Global and StyleOverride Off would certainly be an error.
This would mean that any existing workspaces are not going to see an
improvement, just new ones. Whenever we change these things, all the possible
states have to be looked at, so there may be a hole in some of this. One thing
we try to avoid, but can do, is check the version of the MapBasic program or
workspace and decide what syntax is appropriate. However, this has a
shortc
Re: [MI-L] variable or field not defined
Title: variable or field not defined Dear Ryan I suspect the structure of one of your tables has been changed. Therefore the following message posted by Peter in just the last few days is almost certainly the answer. I enclose Peters posting below. Shows you can learn a lot from reading all the postings! Regards Bob Copy of Peters posting to Lars : Hi Lars,You are right that this might be considered a WAD, sounds better than a BUG anyway ;-)But saving not used settings is exactly what the workspace does, also when it can give the user problems. An example is the label settings for at layer where auto label is turned off. If the user chooses to rename the first text column of a table, the workspace will crash because the "unused" setting for labels is stored in the workspace.And you are right, it should be pretty easy to save this setting to the workspace ...Peter Horsbøll MøllerGIS Developer, MTMGeographical Information & IT COWI A/SOdensevej 95DK-5260 Odense S.Denmark Tel +45 6311 4900Direct +45 6311 4908Mob +45 5156 1045Fax +45 6311 4949E-mail [EMAIL PROTECTED]http://www.cowi.dk/gis - Original Message - From: [EMAIL PROTECTED] To: mapinfo-l@lists.directionsmag.com Sent: Monday, October 23, 2006 7:09 PM Subject: [MI-L] variable or field not defined Hey MapInfo users. Im having an issue lately with opening workspaces in 8.5. I get an error message that says Variable or Field ID not defined. And then it tells me that my workspace is not completely opened, resulting in the loss of my very detailed and painstaking layout which I created. The workspaces were opening fine last week, and no files are missing, have been re-named, or moved. Any help on this would be great, since I am already dreading having to re-create that layout, getting the labels perfect is always a pain. Thanks in advance, Ryan ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
[MI-L] Open Source Donation
Hi List I thought it was interesting to read that last week, at the very time Ian Thomas and a few other list members discussed Open Source on the MapInfo List, Sean O'Sullivan who was one of the original founders of MapInfo, donated $2 million for Open Software development to RPI in Troy. Bob Young MapsByDesign ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] Open Source Donation
Hi Ian Bill beat me to it! The link Bill has given contains a lot more information than the article I read. As Bill said, its very interesting, particularly the comments on "government and consumer applications". Its almost a mirror image of the Oracle approach which charges customers for storing their own data !! Food for thought... Regards Bob - Original Message - From: SCISOFT To: 'Bob Young' ; mapinfo-l@lists.directionsmag.com Sent: Tuesday, October 24, 2006 3:42 PM Subject: RE: [MI-L] Open Source Donation Bob, thats very interesting. Can you point me to the URL? IL ThomasGeoSciSoft - Perth, Australia From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob YoungSent: Tuesday, October 24, 2006 5:44 PMTo: mapinfo-l@lists.directionsmag.comSubject: [MI-L] Open Source Donation Hi List I thought it was interesting to read that last week, at the very time Ian Thomas and a few other list members discussed Open Source on the MapInfo List, Sean O'Sullivan who was one of the original founders of MapInfo, donated $2 million for Open Software development to RPI in Troy. Bob Young MapsByDesign ___MapInfo-L mailing listMapInfo-L@lists.directionsmag.comhttp://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
Re: [MI-L] New Features Wish List
Hi Andy and List Looking at some of these suggestions very positivey I think generally they show some of the very good strengths of the original MapInfo Professional product and its general approach. The purchase price/performance point was /is good and the ability for third parties to develop with MapBasic and later OLE integration has meant that techniques like "hot spotting" can be added by third party specialists. Hence the partner and developer network that work with MapInfo I think is also a positive. If all of the vast range of suggestions were added directly in the core product it would be a "dogs breakfast" and a nightmare to learn - whereas a key strength has been the ease of learning. I think a top wish list should focus on core features that benefit all users and developers and specific verticals are best covered by specialist partners and developers. The GUI and programmability are examples of the core features I mean. Regards Bob - Original Message - From: "Andrew Brumwell" <[EMAIL PROTECTED]> To: Sent: Thursday, October 26, 2006 7:23 AM Subject: [MI-L] New Features Wish List How about a few more analytical features such as: 1) being able to easily identify repeat locations (without doing SQL), 2) aoristic time analysis 3) proper hot-spotting techniques (eg as used by Hot Spot Detective) 4) other spatial/statistics analysis techniques eg Morans I regards Andy Andy Brumwell GIS & Crime Mapping Researcher Force Intelligence West Midlands Police Colmore Circus Queensway Birmingham B4 6NQ 0845 113 5000 x 7800 2653 ___ This email is intended for the addressee only and may contain privileged or confidential information. If received in error, please notify the originator immediately.Any unauthorised use, disclosure, copying or alteration of this email is strictly forbidden. Views or opinions expressed in this email do not necessarily represent those of West Midlands Police. All West Midlands Police email activity is monitored for virus, racist, obscene, or otherwise inappropriate activity. No responsibility is accepted by West Midlands Police for any loss or damage arising in any way from the receipt or use of this email. West Midlands Police - Best performing metropolitan Police service in the country. www.west-midlands.police.uk ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
MI-L Long Lat - what are differences?
Dear List Can someone help please with a question on projections? 99% of time I work with British National Grid projection. Occasionally when I forget to set the default I also get tables in MapInfos default of Longitude/Latitude. I am fully aware of the problems of using different projections, different MBRs etc - thats not the question! In the above though a Long, Lat of say -5,50 might be 201000,195000 in British National Grid say. ie different values for very different co- ordinate systems. However I am now curious as to why MapInfo has so many options for Longitude Latitude. I have found that if you save copy of a standard Long/Lat to say Long/Lat Ireland or Long/Lat (DHDN) ( is this Germany ?) then the x,y values are exactly the same. ie The origin still seems to be equator for Y = 0 and Greenwich for X = 0. SO the question is what is the difference between all the long lats in particular the three above? Why would Germany use DHDN in favour of standard Long/Lat? Sorry about the long intro but I wanted to make sure I explained where my lack of knowledge lies. Regards Bob -- Bob Young - www.bydesignwales.demon.co.uk ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
Re: MI-L Editing the "PRJ" file ???
Hi David Yes but take a backup first !! Then create your own section right at the top of the file eg "--- David Reid Projections ---" "Robinson",12,62,7,0 "Davids Pommie National Grid", 2008, 79, 7, -2, 49, 0.9996012717, 40, -10, 0,0,200,200 "If all else fails (long lat)", 1, 0 If you put this at the top then when you select projections MapInfo will be defaulting to second in list( Long Lat. Just move up the list one place ( to top) and hey presto you have all your fav projections ( ie David Reid Projections). NB the Pommie one has a 2000 added to Transverse Mercator value of 8. This means that a bounding rectangle is specified at the end ( the 0,0 to 200,200. This then increases the accuracy - in this case to 1 millimetre. ... I still do not know why there are all those long lats though? Any ideas? They all seem to store to same origin with same accuracy ( or lack of). Regards Bob By Design In message <004d01c03a18$f2bd6b20$ec41b4d8@dwreid>, David Reid <[EMAIL PROTECTED]> writes >Greetings List, > >Before one gasps, I understand one is at their own risk messing with the >projections file, however. Is it possible to edit the file merely to move >the few most used projections to the top of the list? If so, what other >lines might need to be moved in unison? > >Thanks, > > >David Reid >GIS/Database Mngr >Colbert County E-9-1-1 >Colbert County, Alabama >[EMAIL PROTECTED] > > > > >___ >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, send e-mail to [EMAIL PROTECTED] and >put "unsubscribe MapInfo-L" in the message body. -- Bob Young - www.bydesignwales.demon.co.uk ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
Re: MI-L: MB: Spherical surface mapinfo versus flat surface mapinfo
Hi Michelle I would say this problem is that MapInfo stores coordinates in terms of a whole number times a step size as well reported on this list. If you do not have an MBR on your projection then the step size is the world divided into 2GB. If you cut the size of your MBR to 2000 KM each step would only be 1 mm and the precision would go up. If you cut it to only 200 km your precision would be 0.1mm etc etc Another problem you would have is extrapolating a long distance from a short distance will introduce additional errors. As any surveyor would tell you, you would not expect to accurately set out objects a long way from a theodolite especially when your reference station is close to the theodolite. I do not think this particular problem is to do with curvature because as you say you are assuming its flat in your calcs. Regards Bob By Design In message <00f101c0c317$f8c99b00$[EMAIL PROTECTED]>, m.e.smith@fron tiermapping.com.au writes >I'll admit to being a complete novice when it comes to map >projections/datums etc (Prof. Cliff - if you're out there, please don't >shout at me ;-) !). > >I've always worked on the basic assumption that if I'm using a >longitudinal/latitudanal setup I'm working on a spherical surface, and if >I'm in a map projection (usually AGD or New Zealand Map Projection) that I'm >working on a flat surface. > >I've written a few mapbasic programs (mapbasic defaults to Long/Lat) and >have re-set the coordinate system to that of my mapdata (i.e. a map >projection), assuming that by doing so trigonometry/vectors etc wouldn't be >so difficult (i.e. I could discount the entire "maths on top of a sphere" >scenario). However, although small, errors are introduced that I can't >explain. An example: > >One of my programs takes a linear object (i.e a two-node line, not a >polyline) and uses vectors to extend it by a factor of 10. I can then open >the layer with the original (short) line and and the layer with the newly >created extended line. From a distance they appear to overlap exactly. >However if I zoom right in I'll find that they're actually parallel to one >another, but with a separation of anything between 0.5 and 5cm. Pretty >small, but its causing problems with the rest of the program. (I'm not just >extending lines for the hell of it!). > >Have I reached a limit of precision in MapInfo? Or is my assumption about >using "flat maths" on map projected data incorrect? > >Thanks for any help, > >Michelle > > > >_______ >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, send e-mail to [EMAIL PROTECTED] and >put "unsubscribe MapInfo-L" in the message body. -- Bob Young - www.bydesignwales.demon.co.uk ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
Re: MI-L ntf conversion
Dear Jonathon, David and Raj As well as the offerings listed from CDR and Dotted Eyes there is also MapNTF from By Design. MapNTF has been available since 1993 and has been constantly improved over the years. It is now at Version 6 and offers the following features. It is we believe the only NTF translator to use MapInfos MIMFAL libray. The advantages of this are :- it is the fastest translator and also it is a single stage process with no intermediate files being created, and in particular no mid/mif.The whole process is faster than just the mif/mid import of its competitors. It previews the maps as it translates. On a typical Pentium it is well under a second per tile for full translation. It has always had "style" files which allow you to select what feature code goes where eg 1 layer per feature code or any other grouping. The latest version, Version 6 includes a free copy of our product ProPrinter for viewing and printing MapInfo workspaces and tables, with particular emphasis on incorporation of watermark and OS copyright. There are over 100 users of MapNTF within the UK. This includes police forces, local authorities, National Parks and educational establishments. There are special terms available through Eduserv for the latter. Annual maintenance is available under which updates to new versions are included. By Design have been a MapInfo Strategic Partner since 1993 and version 3 of MapNTF was designed to MapInfos specification for use within the UK, hence the use of the MIMFAL library. There is a free evaluation of MapNTF Version 6 on our website at:- www.mapsbydesign.co.uk You will need to email us at By Design for an evaluation password if you would like to try MapNTF 6 from our website. We are currently working on DNF and support for this will be incorporated in future releases of MapNTF/ProPrinter. I know this site is not for advertising, but I wanted to put the record straight on "major" products available for OS translation ! We believe our product at least deserves a mention ! Regards Bob Young By Design In message <69F3DD82670CD3119C590008C77329750388B185@BVMAILUK01>, Stokes, Jonathan (J) <[EMAIL PROTECTED]> writes >Raj >The major options are as follows > >* Transpose from Dotted Eyes www.dottedeyes.co.uk about 700GBP > >* OSNTFtoMI from CDRgroup www.cdrgroup.co.uk again about 700GBP > >* FME Desktop Professional from Safe Software (Dotted Eyes are the UK >distributor). This is more expensive at 1500-2000GBP > >If you just need an NTF converter buy one of the top two. If you want some >other GIS heavy duty processing tools then buy FME as it does an awful lot >of other rather clever stuff (polygon creation, p in p analysis and a whole >load of other stuff) > >hope this helps > >cheers > >Jonathan > >> -Original Message- >> From:Raj Nagaraj (Deccan) [SMTP:[EMAIL PROTECTED]] >> Sent:Wednesday, April 18, 2001 9:15 PM >> To: [EMAIL PROTECTED] >> Subject: FW: MI-L ntf conversion >> >> Listers, >> >> For the non-academic community, what is the best NTF to MI convertor out >> there, free or otherwise? Thanks. >> >> Regards, >> >> Raj Nagaraj >> >> -Original Message- >> From: Duncan Elder [mailto:[EMAIL PROTECTED]] >> Sent: Friday, March 23, 2001 4:12 AM >> To: [EMAIL PROTECTED] >> Subject: Re: MI-L ntf conversion >> >> >> Listers, >> >> The Academic Community in the UK can access a free NTF to MIF converter >> through the Digimap Service. (http://edina.ac.uk/digimap/) >> >> NTF2MIF is an easy to use translator, for use on Windows PCs and supports >> conversion of all the OS datasets provided through Digimap. >> >> The NTFtoMIF translator currently available at www.mapshop.co.uk >> (http://www.mapshop.co.uk/MiDownloads.htm) only seems to be able to >> convert >> LandLine.PLus OS data. >> >> Regards >> >> Duncan Elder >> >> >> List Sponsor >> Digital GEO data for 125 countries >> LAND INFO International produces digital geographic data for over 125 >> countries. DEMs, satellite imagery, topo maps, vector map layers, >> flood maps, and more. Visit http://www.landinfo.com/indexdm1.htm and let >> our specialists find the right solution. >> ~~ >> >> ___ >> List hosting provided by Directions Magazine | www.directionsmag.com | >> To unsubscribe, send e-mail to [EMAIL PR
Re: MI-L Drawing order within a layer
Hi Berk MapInfo uses an R Tree Structure. As each quad fills up it splits in two to allow more objects to be added that are spatially close to one another - hence the great performance compared with Ake! The drawing order is dictated by the order in the quads, and not by the order you add them or sort them. The only effective way of getting objects on top of objects every time is use of layer control - which is probably no use to you. Hope this brief explanation helps. Bob Young By Design In message <009401c0e522$83535820$[EMAIL PROTECTED]>, Berk Charlton <[EMAIL PROTECTED]> writes >Hello all - > >How does Mapinfo determine the drawing order of objects within the same layer? > >I have overlapping objects within the same layer, and I can't figure out how to >promote some of them to draw on top. I've assumed, perhaps wrongly, that this >is determined by the drawing order of objects within the layer; ie, the objects >that draw last within the layer are drawn on top. > >I've experimented with exporting the layer to a .mif file, and then sorting the >.mif and .mid files based on object type, and then reimporting the layer. >Everything works fine, and the row order reflects the order that the file was >imported. But it still doesn't seem to result in any predictability to how the >objects will be drawn when they are back in .tab format. > >Any suggestions? > >Berk Charlton >Geographic Marketing Solutions > > > >___ >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, send e-mail to [EMAIL PROTECTED] and >put "unsubscribe MapInfo-L" in the message body. -- Bob Young - www.bydesignwales.demon.co.uk ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
Re: MI-L. Convert dwf files.
Hi Listers, Along the same line as Juan except: Does anyone know of any utilities to do the reverse ie convert dxf or dwg into dwf. I am interested in being able to display drawings linked to mapinfo objects. I now have the browser linked to objects in MapInfo but need users to be able to create dwfs - ideally without a copy of AutoCAD. Regards Bob Young Maps By Design In message <[EMAIL PROTECTED]>, Geografa y Electrnica, SA de CV <[EMAIL PROTECTED]> writes >Do you know of an utility to convert a .dwf (autodesk whip) file into dxf, >dwg, tab, shp? I need to see one of these into mapinfo, but can't find a >converter. > >Thanks for your reply. >- > Ing. Juan Pufleau C. >Geografía y Electrónica, SA de CV > Aguascalientes, Mexico >- > > > >___ >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, send e-mail to [EMAIL PROTECTED] and >put "unsubscribe MapInfo-L" in the message body. -- Bob Young - www.bydesignwales.demon.co.uk ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
Re: MI-L centroidx and y
Dear Jacqui This is a regular problem for us UK users! MapInfo is working in a default of lat long, and you are working in British National Grid. You either need to type the projection for BNG into your MapBasic Window or better still set this projection in a default startup.wor so that it is there everytime you start up MapInfo. If you are not sure of the parameters for BNG, take a look in the MapInfow.prj file.( Back it up first if you are going to use an editor!!). Regards Bob Young By Design In message <002001c11c39$43efff00$020a@publish>, Chichester Harbour Conservancy <[EMAIL PROTECTED]> writes > > >Dear List > >I'm sure this is something pathetically simple, but I just can't work it = >out. I have been trying to update two columns with Eastings and = >Northings respectively using Update and then selecting from the = >functions centroidx and centroidy respectively. Usually this works. = >Instead of returning the usual OS NatGrid coords into the columns I am = >getting -1 for the easting and 51 for the Northing, for all points. I = >have checked the projection I am using in Table maintenance and it is OS = >Nat Grid. The cursor location shows OS Nat Grid numbers. Any ideas why = >it sometimes works and sometimes doesn't? =20 > >Cheers > >Jacqui Foskett > > > >___ >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, send e-mail to [EMAIL PROTECTED] and >put "unsubscribe MapInfo-L" in the message body. -- Bob Young - www.bydesignwales.demon.co.uk ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
Re: MI-L How to Stop the Flash on Updates and Deletes...
Hi Arash I think what you want would be impossible. The image you see on the screen has to be painted from the bottom up. When you change the top layer ( the cosmetic) to something smaller MapInfo has to draw all the objects underneath. It does this by reading all the appropriate .MAP files. If first of all wipes the bitmap ( ie draws a white rectangle ) then paints in all the objects in what is known as the "Invalid" rectangle. As computer performance improves and more files are cached I am sure the flash will become imperceptable, but the process, I imagine will stay as described above. Regards Bob Maps By Design [EMAIL PROTECTED] In message <[EMAIL PROTECTED]>, Vakili, Arash <[EMAIL PROTECTED]> writes >I'm creating and deleting objects continuously. >When you delete or update an object on the cosmetic layer or table, >MapInfo will flash the area around the object on the map screen. Anyone >know a method that stops this? > >Thanks >[EMAIL PROTECTED] > > > >___ >List hosting provided by Directions Magazine | www.directionsmag.com | >To unsubscribe, send e-mail to [EMAIL PROTECTED] and >put "unsubscribe MapInfo-L" in the message body. -- Bob Young - www.bydesignwales.demon.co.uk ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
