You might be better referring to them as attributes because property (house/land/apartment) having property(attributes) will get a bit confusing.
Many ecommerce systems use something called an Entity Attribute Value (EAV) table - basically a table that can hold any type of attribute as a key:value store. Its a bit more work to setup, but gives you a more flexible architecture since you can hold anything in it.
Suppose for instance you decide that houses should record if they are brick or wood construction, and you don't have a column for that, then you have to alter the database design to add a 'construction' column, whereas with an EAV store, you would record property_id, 'construction','wood' for instance. New attributes may be added without necessarily having to alter the database design.
If you want to go with a more flat style, yet need to store different attributes per property type, then check this article of mine. If talks about how you might store different user profiles using a polymorphic relationship. The different profiles are the same as your house/apartment/land.
http://novate.co.uk/using-laravel-polymorphic-relationships-for-different-user-profiles/