Why can MySQL handle multiple updates concurrently and PostgreSQL can't?
Rolando already more or less described the reason why the deadlocks happen.  Let me add that PostgreSQL has to take locks on the rows to be updated, in order to maintain consistency.  (now() is fixed to the beginning of the transaction, meaning that two concurrent updates will want to update a given row to a different timestamp, which has to be resolved somehow - taking locks on the rows is the PostgreSQL solution.)

The locks are assigned to the transaction on a first come - first served basis.  Deadlocks occur when two transactions try to obtain locks on the same rows in different order.  The way to do this is - now not surprisingly - requesting the locks in a predictable order.  This is done by

SELECT id -- could be any column, even a constant
FROM position 
WHERE latitude between 234.12 and 235.00
ORDER BY id 
FOR UPDATE;


Here the crucial part is ORDER BY id and FOR UPDATE.  The latter takes the necessary locks of the same type the subsequent UPDATE needs.  

The SELECT ... FOR UPDATE statement might looks superfluous otherwise (especially when you don't need the selected data), and it also means disk writes even before actually changing the data.  This has to be considered when using it.