ROW_LIMIT is ignored in Simbad.query_region*

[bsipocz]

The row limit is ignored at least in the query_region methods, possibly in more (check which methods doesn't use _args_to_payload, ideally all should use it to avoid bugs like this)

>>> from astroquery.simbad import Simbad
>>> simbad = Simbad()
>>> simbad.ROW_LIMIT = 5
>>> simbad.query_region('M42', get_query_payload=True)
{'script': 'votable {main_id,coordinates}\nvotable open\nquery coo 5:35:17.2992 -5:23:27.996 radius=2.0m frame=ICRS equi=2000.0\nvotable close'}

While it's

>>> simbad.query_bibobj('2005A&A.430.165F', get_query_payload=True)
{'script': 'set limit 5\nvotable {main_id,coordinates}\nvotable open\nquery bibobj  2005A&A.430.165F  \nvotable close'}

[eas342]

I had the same problem with Vizier

from astroquery.vizier import Vizier
Vizier.ROW_LIMIT = 10
Vizier(catalog='II/246/out').query_region("NGC 2506",radius='0.3deg',get_query_payload=True)

gives
-source=II/246/out
-out=*
-out.max=50
-c=120.01000647-10.77300605
-c.rd=0.3
-out.meta=huUD
-out.form=mini
-oc.form=d

[eerovaher]

Although astroquery.vizier.Vizier is named like a class (according to PEP 8) and behaves like a class (i.e. Vizier() creates a new object that has the same methods and attributes as Vizier) it is not a class, it is an instance of VizierClass with a __call__() method that returns another instance of VizierClass. Calling Vizier(catalog='II/246/out') therefore creates a new instance of VizierClass with a ROW_LIMIT value inherited from VizierClass and the ROW_LIMIT value of Vizier is irrelevant. Using code analogous to the example in the opening post does work:

from astroquery.vizier import Vizier
vizier = Vizier(catalog='II/246/out')
vizier.ROW_LIMIT = 10
vizier.query_region("NGC 2506",radius='0.3deg',get_query_payload=True)

The problem reported by @eas342 is therefore not the same as the problem reported by @bsipocz.

[bsipocz]

And the behaviour of Vizier is very much the one I would prefer as it allows users to easily set different limits for their different instances in the same session. Though I'm not certain how prevalent this use case is, so I can be convinced otherwise. The main preference is that we should migrate all modules to behave the same way, have the same API principles and that will hopefully help showing users how to do things like changing the row limits, timeouts, etc.

[eas342]

Thank you for the example @eerovaher and explanation @bsipocz !

Perhaps the examples in the docs should also show how to set up an object instance of vizier just like the one above?
https://astroquery.readthedocs.io/en/latest/vizier/vizier.html

[orionlee]

Elaborating on what eas342 suggested, it'd be helpful if the Vizier docs contains information on how to set row_limit on the instance.

One possibility is adding a sub section / note in: https://astroquery.readthedocs.io/en/latest/vizier/vizier.html#specifying-keywords-output-columns-and-constraints-on-columns

It is where the doc that first introduces the use of a Vizier instance.

---

A loosely related issue is that vizier.query_constraints() seems to ignore row_limit , at least for the cases of constraining by a list of IDs. It is the behavior of Vizier server, rather than astroquery. I wonder if it should be called out in the doc.

Example, fetch objects from TESS Input Catalog by a list of TIC ids.

row_limit = 5
vizier = Vizier(catalog="IV/39/tic82", row_limit=row_limit)
print("row_limit in vizier instance:", vizier.ROW_LIMIT)
result = vizier.query_constraints(
    TIC=tic_ids,  # a long list of TIC IDs in string
    cache=False,
)

The row_limit was ignored.

When I enabled debug (astroquery.log.setLevel("DEBUG")), I verified that -out.max=5 is set in the HTTP call, according to the row_limit specified, Vizier sever just ignores it.

While it worked great for my specific case (I forgot to consider row limit, and was happy to find that I got the complete result back), I wonder if the behavior might be surprising to other users.