Looks like coverage is now being abandoned for
SHP. Universal Translator and its E00 headakes may well be behind
us. If all these ESRI shops go SHP then I hope MapInfo get the message and
does SHP better than AkeView. An interesting email for you who deal with
SHP and other ESRI data.
FYI
MidNight Mapper
aka Neil
-----Original Message-----
From: Howard W. Sternberg III <[EMAIL PROTECTED]>
Date: Monday, March 22, 1999 1:15 PM
Subject: SUM: AVE How about long named shape files?
From: Howard W. Sternberg III <[EMAIL PROTECTED]>
Date: Monday, March 22, 1999 1:15 PM
Subject: SUM: AVE How about long named shape files?
A few days ago I asked the following.
For years we've adhered to 8.3 file naming conventions for
ARC/INFO workspaces and coverages, and this has served us well because the data
has been platform independent, allowing us to install it on all Windows and UNIX
machines. Now, however, since Windows 3.1 is history and more users are
hitting our GIS server with ArcExplorer and ArcView, we are finding that the
names we've assigned to these data sources are not to their liking and possibly
should be changed. For the typical user, these data sources are not easily
recognizable. They're seeing things in the dialog box they don't
understand. To them, the names are too short and
cryptic. And on top of that, they'd would rather use shape files than coverages
because they are easier to use. Can you blame them? All they want to
see is more data in shape file format that is named using long file names. So
what do you think? Is this a no brainer, or are there real, hidden
problems with giving shape files long names like NamedLakes.shp,
ommunityWells.shp, NonCommunityWells.shp, etc. If anyone has any
experiences to share on this subject, I'd be really interested in knowing what
happened and why. What does ESRI think? Will Sum. Thanks in
advance.
Howie Sternberg
State of Connecticut, USA
Department of Environmental Protection
Enviromental and Geographic Information
Center
---
Thanks for all of the replies. Rather than
summarize, I decided to send you exactly what everyone said. This way you get
personal opinions, which is often the best way to know how to proceed.
They are in no particular order. As for finding out what ESRI thinks, I
didn't receive anything from them, however, Sara pointed out that in AV3.1 Help
file, under the topic "Converting a theme to a shapefile", the
following is written: "Under Windows, long filenames (over 11
characters) may cause some problems for certain operations. Avoid using long
filenames for files or directories. We recommend following the 8.3 naming
conventions when naming all files." My response to that is whether
ESRI can be a little bit more specific? How about some examples of
"some problems" you might encounter.
--
I'm sure you've seen this already, but the only thing I'm aware of is
to
avoid imbedded spaces. E.g. "Community Wells.shp"
Becky Strauch
avoid imbedded spaces. E.g. "Community Wells.shp"
Becky Strauch
---
Look for a win-win. I would try to find a way to retain the 8.3 at the
deep level for the long run but create a mechanism for the ArcView users to see and obtain a copy of what they want with a long file name. Think
library. There's the old Dewey or LC "name" of the item and then there's
the book's title. Now users may never search by LC number or even look at it. They may think that there's no reason to have these pesky things, but
there is a reason.
Shape file versus coverage...I have same reaction. Keep that coverage but create a mechanism to let 'em eat shape files. The coverage seems so much richer -- I don't know enough about the technical end -- but the whole point of the exercise was all of that rich geography being encoded and you lose some of that with the shape file, don't you?. If users want less, fine. But don't settle for less yourself.
Refuse to let the ArcView tail or user laziness tail wag the dog, so to
speak. Build for the ages. We don't really know where the technology, or
even ArcView, is going. Plus, there is no guarantee that your "long" names or shape files will be more intelligible to the user. Think of some of the folks in your audience, Howie. Is CommunityWell really that much better? I say "utility" you say "company", I say "system" you say "we split up artificially to avoid regulation" ... let's call the whole thing off. I hope this made sense.
Ellen Cromley
---
I use long file names including names with blanks in them for both
files and folders (ie c:\project\New Jersey\app_re_pt.shp) under windows95 and nt both directly from the AV interface (saving and recalling shapes, tables and scripts) and from avenue code and haven't hit a problem within AV yet. Its a pain that I use dBASE III and MS Access 97 to create tables (.dbf's) and they doesn't like any of that stuff so I have to rename them when using the dbf's in other software. If you are only going to use AV then do it.
danny stockdale
---
We run in an NT4 environment, and like to use longer names also.
We
took a different approach, however, because even longer names soon
become cryptic too. We created an Access97 database with a table for layers, shapes, images and ArcInfo coverages, and included a long
free-text description. By creating a query to select data files we want
to release, we are able to call this query in an SQL ODBC call to create
a table in ArcView which we pick up in an Avenue script and display the
long description as a lookup table. Using the REAL file name and an AVL
to attach to it, we Users can load themes with a standard set of
properties (polygon colour, shading, line colour, point symbols, etc)
based on an extended description. The table could be created as a
delimited text file if you don't have a relational database. I will
send you the avenue code if you want it. An added bonus to this
methodology is that we can store and display metadata directly to the
User before they use it.
Hope this gives you some ideas
Bob Davis
City of Melbourne
took a different approach, however, because even longer names soon
become cryptic too. We created an Access97 database with a table for layers, shapes, images and ArcInfo coverages, and included a long
free-text description. By creating a query to select data files we want
to release, we are able to call this query in an SQL ODBC call to create
a table in ArcView which we pick up in an Avenue script and display the
long description as a lookup table. Using the REAL file name and an AVL
to attach to it, we Users can load themes with a standard set of
properties (polygon colour, shading, line colour, point symbols, etc)
based on an extended description. The table could be created as a
delimited text file if you don't have a relational database. I will
send you the avenue code if you want it. An added bonus to this
methodology is that we can store and display metadata directly to the
User before they use it.
Hope this gives you some ideas
Bob Davis
City of Melbourne
---
I use long file names ( with Arcview .shp files ) all of the time and
have
had no problems.
Garry Stewart
had no problems.
Garry Stewart
--
We've used long file names for shape files for a while now. No
problems
with Arcview 3.0a or 3.1. It's probably best to avoid embedded spaces
in the names, however. Problems encountered have to do with using
Shapearc (the PC Arc/Info version) to convert shape files to Arc/Info
format, and editing the .dbf files with dbase since both expect 8.3 file
names and 8-character directory names.
with Arcview 3.0a or 3.1. It's probably best to avoid embedded spaces
in the names, however. Problems encountered have to do with using
Shapearc (the PC Arc/Info version) to convert shape files to Arc/Info
format, and editing the .dbf files with dbase since both expect 8.3 file
names and 8-character directory names.
Mary Howes
---
We use long names and nothing happens. It seems fine although it inherently
makes everyone nervous.
Jill Slater
San Francisco Planning Dept.
Jill Slater
San Francisco Planning Dept.
---
I use long names for shape files I create all the time. Examples
are
"colorado_aircraft_incidents_projected.shp". Makes it easier to remember what the shape files actually represent. Projects work the same way.
Best of luck!
Brad Oleson
GIS/Mapping/Web Site Coordinator
Triax Telecommunications Company, LLC
"colorado_aircraft_incidents_projected.shp". Makes it easier to remember what the shape files actually represent. Projects work the same way.
Best of luck!
Brad Oleson
GIS/Mapping/Web Site Coordinator
Triax Telecommunications Company, LLC
Denver, Colorado
---
If they're hitting a "pre-developed" application, I'm assuming
the Theme names in the legend bar have already been modified to something
less cryptic.
I've worked in places that gave people periodic updates to shapefiles, but I've personally always preferred arc/info coverages. Eventually the whole shapefile conversion system was abandoned. File maintenance was too cumbersome and updates were too irregular.
I loathe the migration away from 8.3 - we have a hybrid UNIX/PC system and the lowest common denominator is 8.3. (If you look at the DOS name,
CommunityWells.shp becomes commun~1.shp, which could be a problem if you also have CommunityStores.shp in the same directory.) We also have people naming things Community Wells.shp (with a space - the UNIX side does NOT like that.) My opinion is that huge hard drives has made users (and programmers!!) sloppy.Filenaming conventions exist for a reason, and no small reason is that the poor guy who has to fix the data would rather type "wells.pat" than CommunityWells.dbf.
I think people tend to whine when not served data on a silver platter. At the old job, we issued a table to serious users with three columns "Cover name", "Feature Types" "Brief Description". They kept it near their PC's and used it for reference. The smart ones accessed it via PC, opened it and did a search on "wells", or "lakes", or "roads" and found the name of the coverage. Eventually, they learned which was which, and rarely needed the list.
Let them learn - we can't do all their thinkin' for 'em!!
Lynn Hay
I've worked in places that gave people periodic updates to shapefiles, but I've personally always preferred arc/info coverages. Eventually the whole shapefile conversion system was abandoned. File maintenance was too cumbersome and updates were too irregular.
I loathe the migration away from 8.3 - we have a hybrid UNIX/PC system and the lowest common denominator is 8.3. (If you look at the DOS name,
CommunityWells.shp becomes commun~1.shp, which could be a problem if you also have CommunityStores.shp in the same directory.) We also have people naming things Community Wells.shp (with a space - the UNIX side does NOT like that.) My opinion is that huge hard drives has made users (and programmers!!) sloppy.Filenaming conventions exist for a reason, and no small reason is that the poor guy who has to fix the data would rather type "wells.pat" than CommunityWells.dbf.
I think people tend to whine when not served data on a silver platter. At the old job, we issued a table to serious users with three columns "Cover name", "Feature Types" "Brief Description". They kept it near their PC's and used it for reference. The smart ones accessed it via PC, opened it and did a search on "wells", or "lakes", or "roads" and found the name of the coverage. Eventually, they learned which was which, and rarely needed the list.
Let them learn - we can't do all their thinkin' for 'em!!
Lynn Hay
---
As far as I can tell, long names for shapefiles are okay. I just made one
last month called congressional_districts.shp. It works with no problem.
Rob Chasan
---
From our experience here, leaving the DOS convention 8.3 is no problem,
even with spaces between the words. This is over our local network,
only,
basically. And, in the form of shapefiles. The only time I have to go back
to the 8.3 is when I use the SHAPEIN command in ArcCAD to convert to a PC ARC/INFO coverage before exporting to an Interchange File if I want to ship it out to ARC/INFO. But it sounds like your users are Win 95, or Win NT anyway, and prefer shapefiles. So, I do not see any problem with what you propose to do.
As a suggestion, to build confidence, back up your work, and then convert
the coverages to shapefiles with non-DOS naming conventions, and "test" it out.
Hope that this helps you.
Randall H Lau
basically. And, in the form of shapefiles. The only time I have to go back
to the 8.3 is when I use the SHAPEIN command in ArcCAD to convert to a PC ARC/INFO coverage before exporting to an Interchange File if I want to ship it out to ARC/INFO. But it sounds like your users are Win 95, or Win NT anyway, and prefer shapefiles. So, I do not see any problem with what you propose to do.
As a suggestion, to build confidence, back up your work, and then convert
the coverages to shapefiles with non-DOS naming conventions, and "test" it out.
Hope that this helps you.
Randall H Lau
---
I'm using ArcView 3.1 with Windows NT 4.0 SP3 and have no problem at all
with long filenames for shapefiles. It's very helpful indeed!! :)
Jeremy Lemley
New Millennium Designs, Inc.
Broadcast Engineering Consultants
---
It has been my experience that no matter what kind of machine,
under
whichever OS, using some version of AV, AI, or PC AI - you can
never
escape the 8.3 naming conventions. As a graduate student, our
lab
contains systems under NT, UNIX, and 3.1 - being a purist (AI on
UNIX)
I have always used the 8.3 naming conventions. With the move to
NT,
those conventions go out the window though.
There have been many
times that the UNIX data I onced moved to NT (with
a longer file name) had to
be put back onto the UNIX box for some reason
- well, you can see that moving
files around creates havok with the
names.
Keep the 8.3 alive - you
never know when those long file names will come
back to bite you in the
butt.
Cheers,
Trevor D
---
I've been using ArcView 3.x on Win95
platforms for over two years now,
always with long file names, including long
names in directory paths.
ArcView has no trouble handling them. Once ArcView
is open, I've never
found a long file name that it hasn't been able to open
as a a project, or
add as a theme or as a table. Two caveats: when trying to
launch ArcView by
double clicking on an *.apr name in Windows Explorer, I
found that ArcView
can't do it if there are space characters anywhere in the
path. So I've
told folks it's best to leave out spaces: not "Named
Lakes" but NamedLakes or Named_Lakes. We also had one instance where the
user had buried his shapefiles about ten folders deep in the directory path, and
ArcView was having trouble finding those. Unfortunately, I don't know the
"whys" behind either of those caveats: both were fairly minor: in
general, I've found no problem with long file names and ArcView.
Joe
Alan Artz
GIS Coordinator
Office of the State Archaeologist
700 S.
Clinton Building
University of Iowa
Iowa City, Iowa
52242
319-384-0795
---
Have been using long file
names for shapefiles. No problems yet. If you want to use a file
name as a parameter be sure not to have any spaces in file
name.
Jason Guthrie
---
This is a great question and I look forward to your summary....especially
if ESRI pipes up!
The only time I ran into problems with the naming conventions exceeding the 8.3 DOS standard is when I transferred a project and the data to another another machine. The machine was a Windows 95 machine and I was taking the data from a UNIX machine. The portability issue was a real headache. The limitation seemed to be the UNIX machine writing to DOS formatted floppies and forced a truncation. This was easily fixed, but a headach at the time.
Beyond that when I am forced to work at the DOS level I have found that cleaning these extended names out result in some problems determining what the correct file is because you cannot see the full name when in DOS. Most of us are very seldom in DOS any more so this is not seen as a problem by many.
What about special characters? Another question that I would like to see you include is what about special characters as well....like spaces, &, dash, and all those other characters we have access to. I find that as a rule-o-thumb I avoid them, but I am finding lots of folks using them. Then if there are some strange problems happening in ArcView (like Spatial Analyst work) I have found that I had to clean out all the special characters to get the software to work.
Since I come from a UNIX background with lots of use of GRID and Spatial Analyst I tend to be very conservative on my naming conventions. This is because I have run into many problems when special characters (including uppercase letters) are used.
I would add the caveot that beyond shapefiles (such as GRIDs and coverages) you really start to run into problems.
Lorri Peltz-Lewis
The only time I ran into problems with the naming conventions exceeding the 8.3 DOS standard is when I transferred a project and the data to another another machine. The machine was a Windows 95 machine and I was taking the data from a UNIX machine. The portability issue was a real headache. The limitation seemed to be the UNIX machine writing to DOS formatted floppies and forced a truncation. This was easily fixed, but a headach at the time.
Beyond that when I am forced to work at the DOS level I have found that cleaning these extended names out result in some problems determining what the correct file is because you cannot see the full name when in DOS. Most of us are very seldom in DOS any more so this is not seen as a problem by many.
What about special characters? Another question that I would like to see you include is what about special characters as well....like spaces, &, dash, and all those other characters we have access to. I find that as a rule-o-thumb I avoid them, but I am finding lots of folks using them. Then if there are some strange problems happening in ArcView (like Spatial Analyst work) I have found that I had to clean out all the special characters to get the software to work.
Since I come from a UNIX background with lots of use of GRID and Spatial Analyst I tend to be very conservative on my naming conventions. This is because I have run into many problems when special characters (including uppercase letters) are used.
I would add the caveot that beyond shapefiles (such as GRIDs and coverages) you really start to run into problems.
Lorri Peltz-Lewis
---
I implemented Arcexplorer on 350 workstations and as you have already
guessed you need to make GIS as easy as possible for non-GIS users. And giving
files a very descriptive names is all part of it.
I created a nightly process that converted the core Arcinfo coverages to shape files then gave each shape file a descriptive name - like you suggested. For example
Administration Boundaries.shp
Oceans-Rivers-and-Lakes.shp
and so on
You can use spaces, but do be careful when using non-alpha characters in file names
I created a nightly process that converted the core Arcinfo coverages to shape files then gave each shape file a descriptive name - like you suggested. For example
Administration Boundaries.shp
Oceans-Rivers-and-Lakes.shp
and so on
You can use spaces, but do be careful when using non-alpha characters in file names
John Jackson
---
I have used long filename in AV3 in
the past. Seemed like a good idea, but then something I was doing (can't
remember what -- it was a while ago)
wouldn't work, and it turned out to be due to the long filenames and
directory names. A big headache; it took days to sort out the problem.
In the AV3.1 Help file, under the topic "Converting a theme to a
shapefile", the following is written:
"Under Windows, long filenames (over 11 characters) may cause some problems for certain operations. Avoid using long filenames for files or
directories. We recommend following the 8.3 naming conventions when naming
all files."
Maybe things will change at version 4?
sarah
wouldn't work, and it turned out to be due to the long filenames and
directory names. A big headache; it took days to sort out the problem.
In the AV3.1 Help file, under the topic "Converting a theme to a
shapefile", the following is written:
"Under Windows, long filenames (over 11 characters) may cause some problems for certain operations. Avoid using long filenames for files or
directories. We recommend following the 8.3 naming conventions when naming
all files."
Maybe things will change at version 4?
sarah
m.s.north
---
Point 1: I am personally a
fan of long filenames. They work well in
unix, Win95/NT, etc. However, I am limited to 8.3 naming conventions if
I want to store anything on my Novell 4.x server, which I almost always
do to lay the backup responsibility on the administrator. I am sure
that some users out there are limited in a similar fashion, although I
hope for eveyone's sake we are in the minority.
Point 2: Spatial Analyst can't handle long filenames in directories.
Isn't that ridiculous? But it's true. I ran into all sorts of problems
when I tried using long filenames when I started with SA. This
convention is not documented as far as I know.
So, if I were a user of your product and I wanted to place information
on the Novell 4.x server, I would really appreciate the use of short
filenames.
Have fun,
Collin O'Neill
unix, Win95/NT, etc. However, I am limited to 8.3 naming conventions if
I want to store anything on my Novell 4.x server, which I almost always
do to lay the backup responsibility on the administrator. I am sure
that some users out there are limited in a similar fashion, although I
hope for eveyone's sake we are in the minority.
Point 2: Spatial Analyst can't handle long filenames in directories.
Isn't that ridiculous? But it's true. I ran into all sorts of problems
when I tried using long filenames when I started with SA. This
convention is not documented as far as I know.
So, if I were a user of your product and I wanted to place information
on the Novell 4.x server, I would really appreciate the use of short
filenames.
Have fun,
Collin O'Neill
---
I've found if I don't stick to the
8 letter convention that Arcview has
problems with the shape files over the long term. Our Head Office has told
us not to use long names for shapefiles.
Cheers,
Danica Birdsall
GIS Project Officer
State Forests of NSW
Eden
Australia
problems with the shape files over the long term. Our Head Office has told
us not to use long names for shapefiles.
Cheers,
Danica Birdsall
GIS Project Officer
State Forests of NSW
Eden
Australia
----
I answered myself. The only other thing
that comes to mind is the inability to transfer long named shape files to an 8.3
compliant Windows 3.11 disk in a computer network environment or zipping and
unzipping with the PKZIP and PKUNZIP dos utilities (you end up with files
like COMMUN~1.SHP). I these situations, you need to shorten the names
before moving or zipping the data.
Howie Sternberg
