Most carparks don't bother giving drivers any indication of how many spaces are available, nor where they are. The only place I have been to which provided any such information was the carpark at the giant leisure resorts in the Genting Highlands in Malaysia. (One day I will include pictures here).
There are two ways of providing this information. The dumb way is just to put a pressure-sensing strip across all entrances and exits, and count the number of axles that traverse. This is very cheap, since traffic meters are used all over the world by road authorities, and reasonably reliable.
The over-the-top-and-pointless way is to plaster the carpark with video cameras, and then use computer image recognition techniques to find the empty spaces versus the full ones. It is only slightly silly, as I will try to explain. Incidentally, I actually started writing some software to implement carpark space identification. It works surprisingly well.
Take a picture of the carpark subset visible from one camera when there are no cars. Do this on a wet day (when the ground is shiny from the water) and a dry day (when the concrete floor is clear). Depending on your location, perhaps an icy day is necessary as well. The orientation of the carpark might force you to take several shots across the day as the sun makes different shadowing patterns. Then, once the system is in use to a sum-of-squares difference between your empty pictures and the picture that may or may not have a car in it. If any of the sum-of-squares is quite small, the space is empty; otherwise it's probably full.
Obviously, you can't just a camera trained exclusively on every space -- even at $AUD100 for a cheap webcam, you still need a lot of USB cabling to drag that back into a computer somewhere to do the processing which will put the price up very quickly. And if you have one camera covering two or more spaces, how is the computer to know where the space starts and ends. I tossed around a number of ideas for this (with Benn Appleton helping). We could force the carpark owner to paint lines on the ground (what about being obscured by something?), or get an operator to mark out the boundary with a touchscreen or trackpad for each space (tedious, error-prone, expensive, still suffers from obscuring).
Anyway, we really want to be looking at the carpark space from above to avoid one car obscuring a free space. So we place a mirror at a 45 degree angle above each space, reflecting the car space at a camera somewhere nearby mounted on the ceiling. Mirrors are cheap to install, and a fixed 45 degree mounting bracket will be very cheap to make in bulk. Obviously, the reflected image won't present the whole carpark floor space to the camera, but that's fine -- even if we are doing sum-of-squares differences just on the space where the car bonnet is, we'll still pick it correctly most of the time.
Better still, we can make the mirrors with a bright purple (or green, or yellow) frame. Any colour that you wouldn't find in a newly-built carpark. The computer can then identify where the mirrors are very quickly. Take a picture when the carparking space is empty, and get an operator to click with a mouse or touchscreen anywhere inside the mirror. (My program asked for coordinators anywhere inside the picture of the mirror, and then found the edge of the mirror itself in just a few seconds of interpreted program time). Then the computer knows which pixels it should sum-of-squares, and also has an initial data blob to compare against.
Since most carparks have security cameras, it might work out that the only hardware needing to be installed is the mirrors (not difficult, since they would be quite robust and no special training is needed), and then splice off the video feed to pass into a computer.
Getting the mirrors aligned is not difficult either. It is a two-person job. One person sits down in the empty carpark space and points one of those red-light pointers that you often see in classrooms or lecture theatres up at the mirror. The other person (at the top of the ladder) rotates the mounting bracket around until the red light spot ends up on the camera lens. Then they bolt the mounting bracket into place.
You could have two different bordered mirrors on each carpark space pointing to different cameras so that you could have two different calculations done. This offers two advantages: even if one camera breaks down, you still know whether a space is free or not; if both cameras are working you can see if there are discrepancies between the images recognised by both (i.e. if one says the space is free and the other says it is occupied, then you can ask for an operator to help out; the resulting information can then be fed back into the algorithm to fine tune how large the sum-of-squares needs to be before the space is declared occupied.)
One useful piece of data that can come out of this is reporting back to the carpark operator how utilised the spaces are. For example; the disabled spaces are only occupied 20%-80% of the time and there are always spares (so therefore remove some). Or, by looking at when changes of state (occupied to free, free to occupied) occur, you can get duration information -- 15% of your customers stay for under 25 minutes (so include more short-term parking spaces). Some of this sort of information is available for pay-to-park stations from their ticketing, but this can give real-time data.
The feedback that you give to drivers depends on your country's driving and parking ethic. In Australia, most carparks are run as a service for a large shopping mall. The aim is to make it easy for people to park, so the carpark is sized for maximum capacity (usually Christmas). Feedback is simple -- there are 23 spaces on level 3, 12 on level 2 and none on level 1. (Note that even if the system is not always accurately identifying free-vs-occupied, the qualitative information of "lots of space on level three, none of level one" is sufficient for drivers to make informed decisions).
In Malaysia, on the other hand, a carpark is likely to be a profit-focussed business. So it is sized to be small enough to be permanently occupied. Now things get harder. You first run the system for a while to build up a statistical distribution of stay durations. (e.g. 15% stay one hour, 45% stay one hour to two hours, etc.) Once this is in place, the system can then report to drivers "expected wait: 15 minutes on level one, 22 minutes on level two, etc.". It can do this by looking at the number of cars that entered level one, and then left within an hour versus the number of cars it would expect to have seen leave. The mathematics for this will be quite complicated, but do-able nonetheless!