Google Maps API - reading locations from file and displaying markers on map
Your Marker and ShelterObject instances have the same data inside. (except the additional hardcoded (!) string "Antal platser:", whatever that means) Now you have two islands of data. You collect them in two different lists, shelterObjects and shelterMarkers. That is bad, High memory usage and difficult modifications are the drawback. If you want to add/delete/modify one you have to to it in two lists and keep it synchronized. I recommend to only have one island of data (ShelterObjects-array) and whenever you need ShelterMarkers, you convert them. For example you can add a method getAsMarker() to your ShelterObject class that returns itself as Marker. If you have enough memory and want to save performance you only create them when needed and store them for later re-use(see Lazy Instantiation), like so   

class ShelterObject {
   ...
   int Marker marker;
   public Marker getAsMarker(... mMap) { // or pass mMap in constructor. 
      if (marker != null) {
         return marker;
      }
      LatLng geoPosition = new LatLng(this.getLatitude(), this.getLongitude());
      marker = mMap.addMarker(...); // creates marker via MarkerOptions
      return marker;
   }
   ...
}

What is "LatLng"? You barely can speak that out. If you mean just a pair of latitude and longitude coordinates, then just name it like that: geoPosition, coordinates, latitudeAndLongitude. Try to use short and meaningful names, but no abbreviations. In old times, even Microsoft used code abbreviations like "lptcstr" (google it). Because of bad experience, this is discouraged now. I can't count how many times I have looked up which combination of manager and number the managerNumber was abbreviated: "num", "nbr", "no", "numero", "man", "mgr", "mangr" etc.
Delete the code line below. You overwrite it right away, so you can leave it out for less code clutter.

String line = "";
You forgot to close your stream in a finally-statement of your try-block. This is a severe bug since it's hard to detect when files remain open and suddenly your program crashes when it runs out of file handles. Alternatively you can use a try-with-resources statement. 
Avoid using member variables like they are global. Just pass them as parameters. You can better test it and make your code more stable.
I will give you an example what I mean:
Assume you have following lines inside your init-method:

generateShelterObjects();
addShelterMarkersToMap();


Now somebody changes it to following code that crashes or does not add the shelterMarkers:

addShelterMarkersToMap();
generateShelterObjects();


Does he know that he is not allowed to swap the lines when he needs to refactor?
Maybe he does it by accident?

You can avoid that by coding:

ArrayList&lt;ShelterObject&gt; newShelterObjects = generateShelterObjects();
ArrayList&lt;Markers&gt; newShelterMarkers = addShelterMarkersToMap(shelterObjects);
shelterMarkers = newShelterMarkers;
shelterObjects = newShelterObjects;


Now when you swap the first two lines, it will not compile anymore. Also there is no possibility that you can have a nullPointerException in addShelterMarkersToMap() anymore. (I assume that you return an empty Map instead of null in generateShelterObjects() or throw an exception there).
You also cannot have inconsistent data anymore. Just imagine in generateShelterObjects() your map is half-filled when an error occurs. Or your markers are half created when an error occurs. You need to catch the exception and clean both maps. Having inconsistent data is worse than just keeping the old, consistent ones.


Use "/** comment **/" instead of "// comment" on top of your methods, so you can create javadocs easily and the IDE can show it as mouseover-message