I have 250 fields(comlumns) in excel. Can I create a shapefile? What is the work around?

[OzKhan]

I have 252 fields as a .CSV file. I would like to create a shapefile but I get the following error...

What is the work around for this?

Thanks,

[JoeBorgione]

Shapefile or feature class?  250 columns for any database table is poor design IMHO.

[JoshuaBixby]

I agree with Joe, that many columns typically represents a poor data design, especially considering your sample data has roughly 200 fields unpopulated.  That said, what tool are you using?

[JoeBorgione]

....especially considering .... 200 fields unpopulated

I didn't even open it. Good catch!

[DanPatterson_Retired]

Not to mention, that you haven't indicated how many rows and whether all those rows are fully populated or whether the fields are of a unique data type.  Clean it up, get rid of the extra pages... lean and clean, no blank rows, no spaces in column headers, unique data type per column... you might have a good chance.

[TedKowal]

I agree with all that was stated in the chain --- bad design -- however I feel pain sometime your stuck dealing with issues like this.... I can give you a technique I use when dealing with  large amount of columns.....

Export in multiple passes with smaller number of columns...

First create a numeric column in your spread sheet and fill it with sequential numbers ending with your last row this will be you "own" uniqueId -- call it MYID now export MyID, col 1-25  as a table in access -- export MyID, col 26-50 -- and so on as a table in access.

Now you can manipulate your data within a real database.... In GIS you can join the tables based upon "MYID' and recreate the 250+ columns of data

[TedKowal]

I have attached a mdx and personal database that has 75 of your columns seperately exported and re-attached in GIS in various of ways:

1. with joins

2. as an exported feature class containing all of the columns

This was using the same technique as a described earlier.

[OzKhan]

HI fellow GIS users and experts,

Firstly I would like to apologize for not describing the project. I do realize that this is a poor design but I couldn't think of anything better. I attached a sample with 5 rows but it will have 480 rows. So let me discuss what I am looking at...

I am going to have 480 rows in total. The data contains field inventory of pedestrian ramps across 480 intersections in one county. Each intersections may have one to twenty pedestrian curb ramps (pedestrian ramps in sidewalks, roundabouts, medians, porkchops etc). We have about 10 elements for each curb ramps and each needs its own column. So at the extreme, the database could have as many as 10 x 20 = 200 columns with all of the evaluation criteria for up to 20 curb ramps at one intersection.We don't have the budget to individually create points for each ramps at an intersection. Also, that would cluster too many data for a single location if displayed on a high level. Note that not all the fields may be populated for a single intersection.

Can you suggest me what could be perhaps a good option to design a fair database?

[TedKowal]

Here are some publications with lots of information and contacts to assist you in designing a better schema for your data....

Best Practices in Geographic Information Systems-based Transportation Asset Management | Federal Hig... 

Proposed features/sidewalk schema - OpenStreetMap Wiki 

[JoeBorgione]

480 points isn't that tough to manage.  However you might want consider related tables of 'pedestrian ramps in sidewalks, roundabouts, medians, porkchops etc'.  Sounds like not all intersections have all these various types associated with them, so for my money, relationship classes are the way to go.