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
>>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, 400000, -100000
>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: 18395

Reply via email to